This is hopefully obvious, but if we go down the path described in this thread we need to plan for extensive user testing and hypothesis validation. While such a significant UI delta from the norm on mobile could set us apart, it could also easily sink us.
That said, I'm completely on board to give it a go and I can work with the UX team to expand on the work that has been done so far listed in this thread. Ideally we'll have a few options which each set out to solve a subset of the problem space. >From my perspective, the problem space probably boils down to a few key things: 1) Firefox OS is at a disadvantage with respect to availability of mobile "apps" and while the Web is a massive content repository the user experience of accessing Web content is often poor. The content consumption experience on Firefox OS needs to be world-class. (we'll have to figure out how to make this measurable) 2) Current mobile app models break content acquisition and consumption flows leading to difficulty in accessing content or increases in the time required to complete a task. (This includes being forced to download mobile apps, the inability to search within and directly access app-based content and the maintenance required for an app-based content model including dealing with the actual icons and app updates) In addition, it sounds like there is an additional argument that task management, including multi-tasking, is arduous on current mobile OSs. That hypothesis probably needs some validation as I suspect it is only a problem for a certain type of user (but I've not seen data on this) or the cause of people not using mobile devices to multi-task is attributed to constraints like screen size and input methods rather than session management capabilities. The discussion in this thread is targeted at a large part of the problem space, but we'll also need strategies for the other aspects of content acquisition/consumption including search and discovery. (Marketplace is a key part, but so too are third party service relationships) Peter Dolanjski Firefox OS Product Management On Wed, May 13, 2015 at 3:39 AM, Thomas Zimmermann <[email protected]> wrote: > Hi > > >> > >> 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 :) > > I promise to not sue you for copyright violation. :D > > > > > 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. > > I agree. > > When creating these mock-up images, I noticed how hard it is to make the > new "Tile screen with background picture" visually different from a > traditional Home screen. As soon as I added an image in the background > it looked more like the Home screen and less like the Tile screen. Maybe > there needs to be a one-pixel frame, connecting top and bottom menus. Or > the menus and icons need different shading and shadowing. > > Best regards > Thomas > > > > > / 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 >
_______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
