The first thing comes to my mind would be: we will spend lots of time to do "page" switch and the user will notice the "delay" unless we are doing something nice to avoid that.
A good but not best reason to keep "one app, one window" model is we could put some preload stuff in the same window before it gets loaded, like screenshot or app splash. I am not sure what we could do if we are using the same window for all pages. Is it navigation transition or something else? 2015-05-12 7:10 GMT+08:00 Jonas Sicking <[email protected]>: > 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
