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. 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
