Product Ideas Portal

AMP Reports should support a combination of Web and iOS/Android BPs/testing in the same report for "hybrid" mobile apps

When an AMP Report is first created, a single 'Technology Platform' must be

specified, such as Web, Adobe Acrobat PDF, or iOS. Only that platform's Best

Practices will be offered for testing and violation entry. (Web reports offer

support for PDFs, but that's the exception.)

 

Many/most so-called "mobile apps" are truly 100% native iOS (Xcode) or native

Android (Studio), and those require separate sets of Best Practices to be

used. At the other end of the spectrum, some "mobile apps" are "hybrid" but

where the app (downloaded from the appropriate App Store) merely serves as a

wrapper or container for a Webview that actually renders up to 100% of the

content and controls that are just as HTML-based as the responsive web site

that often populates their Webview, in its entirety. Other "hybrid" apps fall

anywhere along the spectrum, with some combiantion of native and webview

controls/content. Might be 50/50, 95/5, 75/25, and that can vary by screen,

etc.

 

But we (Level Access Accessibility Services) are not well-positioned to know

this and it's not readily determinable (button button, everybody's got

buttons!) and must rely primarily on the client to inform us what the mix is -

what's native and what's web. Clients using AMP to audit their own "mobile

apps" would hopefully have this information directly. But the dilemma is the

same for both - each AMP report can only offer ONE set of Best Practices for

testing checklist and violation entry. Web results/guidance offered for what

is a native control is "not completely useful", and vice versa (native

iOS/Android guidance for Web/HTML controls/content).

 

Thus this request, to allow the tester to utilize testing checklists of best

practices and enter violations that could be Web or could be native

iOS/Android - all in the same module and the same AMP Report. Currently,

absent this capability, there is a risk of the "wrong" Technology Platform's

best practices being used, or some awkward combination of one Web report and a

separate iOS/Android report for the native controls might be used.

For AMP report creation, manual testing checklists, possibly also automated testing using AMP for Mobile, violation entry, and violation reporting & filtering, add support for multiple Technology Platforms a single AMP Report for testing hybrid mobile apps.

 Thank you.

  • Mike Schutte
  • Jan 25 2018
  • Deferred to Next Gen
  • Attach files
  • peter johnee1 commented
    4 Nov 02:54am

    Don’t cry over the past, it’s gone. Don’t stress about the future, cookie clicker it hasn’t arrived. Live in the present and make it beautiful

  • Mona kell commented
    8 Sep 01:02pm

    This was very informative... Webview that actually renders up to 100% of the

    content and controls that are just as HTML-based as the responsive web site.

  • Henry Crabtree commented
    31 Aug 09:10am

    Thanks for the information, I am an SQA automation engineer and for testing the hybrid apps I bought Asus laptop from labor day coupons at reecoupons. Now on my new laptop, I can use automation technics to test apps and create reports.

  • Marty Strauss commented
    29 Oct, 2019 04:24pm

    Great, thank you for that update Megan!

  • Admin
    Megan Alfaro commented
    29 Oct, 2019 04:21pm

    Hi Marty,

    Right now it's not possible within the current AMP architecture, which is why we moved it to NextGen. We are including this in our Next Generation platform and will update everyone via this Idea until a ticket is created, and we'll link the ticket here as well. Thanks!

  • Marty Strauss commented
    28 Oct, 2019 08:05pm

    Hi product team, this idea has now been deferred for over a year since it was acknowledged and nearly two years since the idea was brought up.  Can you please provide an update on when you expect to implement it?  It is still a significant issue.  Thank you!

  • Kevin Murphy commented
    3 Dec, 2018 01:35am

    Oh, and I just need to mention, that there is no way that someone scoping this would have known this. It only became apparent after testing. So doing something where you have to redo the report and adding in the other best practice set isn't practical. This needs to be able done on the fly or by default. 

  • Kevin Murphy commented
    3 Dec, 2018 01:30am

    Just coming to chime in that I'm running into this exact same issue right now, where the iOS app at a certain point is just a shell to the client's website, which has many significant issues that are outside the iOS best practices. Maybe just adding a best practice in mobile along the lines of "web-based errors within mobile" or something that isn't tied to anything specific, where we could put in our own observations, would be a good stopgap.  

  • Admin
    Megan Alfaro commented
    6 Aug, 2018 03:09pm

    Agree that this is a good idea, but it will take significant time and we'll address in the future.