On Feb 7, 2014, at 8:59 PM, Antonio Manuel Amaya Calvo wrote: > On 04/02/2014 11:00, Frederik Braun wrote: >> On 27.01.2014 15:35, Fernando Jiménez Moreno wrote: >>> Hi folks! >>> >>> tl;dr: I would like to change the current trusted UI by: >>> >>> 1. A system dialog enabled via hardware buttons. >> This is tempting, but I don't know if UX likes it if the home button has >> an implicit second meaning. >>> 2. Extra information about web apps. >> I think the cards view (task manager?) is a possible good place for >> this. Paul said on IRC he remembered that there was a demo or a mock-up >> where you could flip the app card and see some info about it. That would >> be interesting. > Card view could be a good place for this. In fact, we're already showing > the URL of the page being shown on the cardview when the domain is > different than the app domain. That is, if you're on the app > "Fantabulous App" and the content being shown belongs to the app, then > the card view shows "Fantabulous App", but if it's showing a page from > http://anotherdifferentdomain.com then it shows > http://anotherdifferentdomain.com (or as much as that as it fits on the > window). > > The problem I see with that is that there should be also something on > what the user is actually seeing that tells him that something is > different about that dialog, that it comes from the system. The idea > behind Trusted UI was not as much rethinking the SSL indicator as to > have some way of telling the user 'hey, you can trust this dialog > content because it's been loaded by the OS, nor by any app'. Or more > concise: This dialog is owned by the operating system.
The main thing that bugs me about the current trusted UI is that we use it to load remote content, and content that is worth spoofing (since in the payment flow the user is asked for PIN & payment information). So to the user it looks like it is part of the system, but in actual fact it is loading a remote web page. > > That's a much simple trust decision. Showing the information on the card > view can fill the same role (we can say there also the owner of the > window) but it hides it from plain sight. > > >> >> If all is lost and nobody wants to innovate, we could still display a >> lock in the notification bar that indicates the status of the current app :( > And the problem with this (and also with the rocket bar) is that a full > screen app can imitate this without much problem (they can even copy the > code we use to show that :)). I could be wrong, but if we have a way to shown the rocketbar in fullscreen, can't we ensure that the rocketbar is always shown when you swipe down from the top? And therefore have a way to ensure that the _real_ rocketbar is always shown. I guess what I'm hoping is that the "swipe from top of screen" gesture can be made unspoofable in the same way that a homescreen button is unspoofable. Not sure if this is actually possible though. Can this be done by catching gesture events somehow? Or could a fullscreen app intercept these events? > > > Best regards, > > Antonio > >> _______________________________________________ >> dev-b2g mailing list >> [email protected] >> https://lists.mozilla.org/listinfo/dev-b2g > > > ________________________________ > > Este mensaje se dirige exclusivamente a su destinatario. Puede consultar > nuestra política de envío y recepción de correo electrónico en el enlace > situado más abajo. > This message is intended exclusively for its addressee. We only send and > receive email on the basis of the terms set out at: > http://www.tid.es/ES/PAGINAS/disclaimer.aspx > _______________________________________________ > dev-b2g mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-b2g _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
