On Tue, May 12, 2015 at 2:59 AM, Thomas Zimmermann <[email protected]> wrote: > Hi Jonas, > > your proposal reminds me of the 'Browser-like UI' concept I submitted > during the ideation process. The UI would use tabs for navigation and > the home screen would work like the Tiles page on Desktop/Android. I > uploaded the presentation's PDF to > > https://people.mozilla.org/~tzimmermann/browser-like_ui.pdf > > It also contains some mock-up images based on an older UI of Firefox > Android.
Yup, I agree, there's a lot of similarities. I shall make no claims to have thought of this first :) One thing that I do think is critical is that we enable users to access the "new tab" and "switch tab" UI from anywhere in the OS. Including when using the dialer and the homescreen. / Jonas > Best regards > Thomas > > > Am 12.05.2015 um 01:10 schrieb Jonas Sicking: >> Hi All, >> >> We've debated various forms of making FirefoxOS more webby and less >> app focused. The new security model is one example of that. The >> pinning proposals from Ben is another. >> >> I have several goals with this: >> >> First off, I think creating something more webby means providing a >> significant differentiator to Android/iOS. We can create something >> which cause people to not just count the number of apps that we have, >> but instead look at other differences. >> >> Second, I think the web model provides substantial benefits. All >> modern operating systems, desktop and mobile alike, use an application >> model. But this model came about due to engineering reasons, not for >> UX reasons. On desktop the web model has proven remarkably popular and >> successful, and I see no reason why it couldn't on mobile too. >> >> Third, by creating something more webby, I think we'll make better use >> of the content that we have. I.e. it'll make better use of the web as >> it is and as it will be for the near term future. >> >> >> So what does "more webby" mean. I'd like to take inspiration for how >> desktop browsers work. >> >> On a desktop browser we separate "browser UI", aka "chrome", from "web >> content", aka "content". >> We generally render the content front and center and let it take up >> the majority of the window. >> >> The chrome provides two things: A navigation UI which sits around the >> edges of the window, as well as various pages, like about:home and >> about:preferences which is rendered in the area where we otherwise >> render content. >> >> An important part of the navigation UI is session management, which on >> desktop is done in the form of tabs. Tabs let you create any number of >> sessions and let you quickly switch between them. >> >> The chrome always surround the area where we render content. But >> sometimes we also display chrome in the area normally used by content, >> for example for about:home and about:preferences. >> >> >> So we could do the same thing for FirefoxOS. Lets treat Gaia as >> "chrome" from a user point of view, i.e. as "Phone UI" (or "TV UI" or >> whatever product that we're building). This doesn't mean that we >> should give it with Gecko chrome privileges though, I think there's >> still good reasons not to. >> >> This UI should provide both navigation UI, as well as UI for home >> screen, phone calls, text messages, camera, and whatever other >> functionality that we think built-in UI should have. >> >> >> So, starting with the navigation UI, I think we should follow >> desktop's lead and leave session management up to the user. So like >> how we don't open bookmarks in new tabs on desktop, I don't think we >> should open icons on the homepage in a new window. >> >> So by default I think there is only a single window. This window >> starts with the homescreen, and when the user clicks an icon, this >> window is navigated to whatever URL that icon represents. >> >> This includes if the icon that was clicked is for the dialer or some >> other Gaia content. It even includes clicking the "home" button. The >> home simply acts like a bookmark which navigates the user to the >> homescreen. >> >> To enable the user to open a second session, we should have an >> explicit UI action which opens a new window, similar to how desktop >> has a UI action for opening a new tab. The user then stays in this >> tab, no matter which links are clicked or websites are navigated to. >> >> Any background window is unaffected by what the user does in the >> foreground window. This might mean that the user has the same gaia >> content open in two sessions at once. Even the homescreen might be >> open in multiple sessions at once. >> >> We can then enable the user to quickly switch between open sessions, >> or close any session. If the user close the last open session we can >> create a new session open at the homescreen. >> >> This means that the the current "task manager" UI becomes a "session >> manager" rather than a "app manager". We might also want to make >> bigger changes to that UI given that its primary use-case changes. But >> I'll leave that to a separate discussion. >> >> It also means that we more clearly always have something to go "back" >> to. I.e. the previous page that you visited in the current session. >> This means that we could hook up edge gestures to perform >> back/forward, or we could even include back/forward hardware keys if >> we want. >> >> Note that session management can be orthogonal to which content runs >> in which process. So just because the user stays within the same >> window when navigating between gaia and non-gaia content, or between >> different gaia content, doesn't mean that we need to stay within the >> same OS process. >> >> >> This also greatly changes what we can do with the rest of Gaia. Since >> it's all just part of the "phone UI" that this means that we don't >> have to have separate "apps" for the phone UI, text message UI, >> camera, etc. Its all just "phone UI" to the user, the same way that >> about:preferences and about:home is part of the browser UI on desktop. >> >> We might still want to separate various pieces of Gaia into separate >> origins or cookie jars for security reasons. And we might still want >> to use separate processes in order to prevent OOMs in one area of the >> UI from bringing down other UI. >> >> But by simply treating all of Gaia as "Phone UI" it means that we can >> make process and origin decisions independently from UX decisions. So >> for example dialer, messaging and contacts could be put into the same >> gaia package which means that they share IndexedDB and localStorage >> data. >> >> In fact, the only really strong reason to split different parts of >> gaia up is to security-wise separate some parts from others, just in >> case something gets hacked. So for example the email app deals with a >> lot of untrusted 3rd-party content which makes it more prone to get >> hacked, and so makes sense to separate from most other content. The >> same might be true for the media apps. >> >> >> There are of course a lot of details to iron out. Such as what happens >> if a webpage call window.open() or uses <a href="..." >> target="_blank">. On desktop that creates a new session in the form of >> a new window or tab. Do we want to do that here too even though we're >> saying that users are in charge of sessions? >> >> And when do we hide/compress the URL bar? Does it >> appears/disappear/compress/decompress when you navigate between >> gaia/pinned/unpinned content? >> >> We also need some way to go back to content which you have previously >> visited, but which you didn't save in a dedicated session. Something >> like the rocketbar or even a dedicated history UI could help here. >> >> These are clearly things we need to figure out, but I hope these >> things can be reasonably solved. >> >> >> So, in summary, the idea is to: >> * Don't use separate windows for separate "apps" >> * Enable platform-wide "tabs" which can be navigated to any URL, >> including gaia URLs. >> * The same URL can be open in multiple tabs at once, including gaia >> URLs. Even including the homescreen. >> * Icons on the homescreen are just like links and just navigates the >> current tab. >> * The homebutton simply navigates the current tab to the homescreen URL. >> >> Thoughts? >> >> / Jonas >> _______________________________________________ >> 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
