Hey Steve;Bob and I took a look at this, tried to replicate it, but
didn't observe what we understand you're seeing.On an iPhone, an iPad,
and Android tablet -- all show similar interactions of transparency. The
notable differences have more to do with brightness of the
device.Something we're not completely clear on is where you expect to
see card transparency.Certain properties of a card can be transparent:
card background color, image tint, and text background color support
this.Text is opaque...
Read Bob's message again, carefully.If you intend to have different
articles and organization for phone and tablet, you'd want two
top-levels.If you're building different phone and tablet, pixel-perfect
content, you'd want two top-levels.If you want the same content and
organization on both phone and tablet, one top-level will make things
easier.If your content is HTML-based with good CSS, it can adapt to both
phone and tablet, and one top-level is great.If your content is
pixel-perfect and you ...
Hey Taina;I have engineering looking into this. They're trying to find
an S5 to test with, we tried a S6 and it received the phone rendition.
I'll let you know what I find out.BTW, your technique of adding a
collection and using different card designs calling different metadata
is quite clever. Nice technique.
All suggestions above are good, although some of the AirPlay-like will
require being on a common wifi network AND subnet. And that can be
challenging sometimes.OTOH, for the big screen you may have a switch for
inputs, then you could use an adapter that connects the iOS device to
the projection system. If you do that, I'd tape the adapter to the
device--wiggling wires can be an issue.
Taina -- thanks for splitting this question off.I did a really quick
test with my iPhone 5S and a Motorola that has dimensions that match the
Galaxy S5 -- they both see my phone layout rendition -- I think that's
what you expect.So you have two apps in one project -- cool, they both
see the same content.-- The card images will be the same since all
content is the same.-- May I assume you have one top-level?-- -- If you
have two-top level and different phone and tablet collection structures
Hey Bill;I think you're describing some of the navigation features we
had in the original DPS. The scrolling navigation through articles in a
folio isn't part of the newer product. I suspect it comes down to a
folio had information about all the articles that were in it, whereas a
collection is a more flexible container and doesn't carry the
information that would support scrolling with thumbnails of each
Taina;If I understand your situation correctly: you see the phone
rendition on iPhone and tablet rendition on the Samsung -- but they look
different... I think your issue is different that DPS Admin's in this
topic. If this is the case, would you start a new forum thread for your
topic? This would help engineering. Thanks.
Some devices and OSs do some interesting pixel-doubling, and I have a
hard time articulating exactly what goes on. OTOH, looks like you have a
value for the Layout Templates system that let's you emulate what you're
seeing on the device.
Device choice should be influenced by your expected audience (or maybe
you have data on your audience.)Is an iPad audience a primary user set?
Or is it phone based?Where are most of your users based? The North
American market is different than Europe or Asia.Is your app aimed more
at on-the-go consumption (phone) or not-as-mobile (tablet)?Old device
may use old OSs, so what should you support? HTH
I asked engineering about phone v tablet for layouts. Apparently AEMM
looks at the width to determine whether a device is a phone or tablet.
If the device is 600 pixels or wider, it's going to use the tablet
layout. Less than 600 will use the phone layout. -- A device that's 720
is going to use the tablet layout. And that's what I see in the
screenshot.But the card looks odd to me, this is based solely on my
assumptions and a couple of screenshots. Since we know your device is
going to call the ...
Consideration = still looking at it, no timeline I can share.PMs make
the judgement of how difficult something is and how many resources are
needed to implement. Sometimes PMs will tip their cards.The workaround I
shared with KDR was a way to maybe address her need. But it's not a real
solution. Yes, I have to be cagey on this topic. Hopefully my sharing a
little information is better than no response.
There seem to be at least four things going on here, so simple answers
are going to be difficult.One variable is how you're building your
article -- seems like you're using InDesign rather than HTML. Within
InDesign there are two ways to approach this: a video overlay or a web
overlay -- each has different features.An InDesign video overlay has the
most control over playback (full screen option) and you can embed or
stream the video resource. This is the option Benoit is covering above.
Hey Benoit;I've developed a habit of using Chrome when working in the
AEMMobile Portal. I started doing this way back in the beta period
nearly a year ago when Safari didn't display some things well. I've kept
on using Chrome for the portal since then, this includes using incognito
browser pages so that I can log into the portal with different
accounts/projects at the same time.HTH
One thing to check is whether the mute switch is on.AEMM apps respect
the position of this control (it's a soft switch in the bottom controls
(swipe up from the bottom of the screen) but iOS apps (browser and
music) will play through the speaker regardless of the setting.I've been
caught by this, engineering has been caught by this, you might be as
well. Easy to fix though.
Hey Jenn;Back in mid-March this topic was going on:Cards titles look
different when publishedIt seems that iOS apps prefer leading of 1.1 or
greater. Leading less than this value don't work as expected.In a
related forum thread it was discovered that if you need to include the
zero before the decimal place. Enter 0.9; entering only ".9" would
become "9" -- but entering "0.9" would work -- but poorly for iOS
currently.Adobe PMs are aware of these problems.HTH
Based on a recent question: what are the type specs for the metadata
used on that card? A previous question came down to a leading value of
less than 1.0 on iOS not displaying the same way as on Android. Your
settings might be a new data point for how leading values are working on
iOS.A long shot, but potentially interesting.HTH
I avoid roadmap questions, for a number of reasons... so "no comment" on
this. If a PM wants to comment, cool.OTOH, make your case for why an
email action for a banner would change your business... PMs appreciate
that type of information on feature requests.
The PDF converter is a convenient way to port content into AEM Mobile --
but I'm not aware of any plans to add tools to the converter to build
custom navigation.You get page based, swipe navigation. That's basically
it. I suppose you could work in Acrobat to add buttons that use relative
navto syntax, but that feels like a lot of dubious work.Alternately, if
you're working with a large document, you might split out chapters or
sections and then convert these portions of the larger PDF into artic...
Got it. Sorry I missed that you're mostly focused on the fonts.So what
fonts did you load? Type/format.The iOS and Android apps will tend to
use the TTF or OTF font resource, Windows will want a WOFF format, and
the Layout Templates will also want a WOFF resource.
A quick comparison of the two images and it strikes me that the
treatment of the cards and banners is the same. Line ends, crops, grids
are the same... What's different is that Layout Templates doesn't show
the OS bar at the top and it doesn't "crop" the page to only show the
aspect ratio of the iPad... so I have the impression that the preview in
Layout Templates is the wrong shape, specifically it's too tall.So the
impression from Layout Templates is that I'll see all of the third row
Linking in an AEMM app uses navto -- take a look at Hyperlinks in AEM
Mobile for information about the syntax.If your articles are built with
InDesign, the links need to use navto.If your articles are HTML, links
use navto instead of http.Navto includes support for linking to a page
or into the article, it's covered in the Help topic.HTH -- Colin