User:David Regev/Ubiquitous Firefox Revisited: Difference between revisions

User:David Regev/Ubiquitous Firefox Revisited (view source)

Revision as of 17:15, 18 December 2012

11,888 bytes added , 18 December 2012

m

Afterword – First Draft

David Regev

Confirmed users

187

edits

@@ Line 92: / Line 92: @@
 '''''The afterword was originally posted in as a comment [https://groups.google.com/d/topic/mozilla-labs-concept-series/ukr4Qgl9_dk/discussion in the discussion] of this concept.'''''
+Thanks to a fruitful and insightful discussion, I’d like to revisit the concept with some answers to the questions I asked at the end of my proposal, along with some new idea to modify and compliment the design. I will also discuss how we might implement this system, and what needs to done now.
+===Some Answers===
+'''Stack Design.''' Instead of the physically-confusing way in which I originally placed cards in a stack, the stack should look more like a fan of cards, the topmost one at the left:
+[http://www.thecuso.info/wp-content/uploads/2009/10/LeftyFAn.jpg http://www.thecuso.info/wp-content/uploads/2009/10/LeftyFAn.jpg]
+Additionally, the fan would be split in the middle, with the currently-focused page sticking out. The result is that two pages are always fully visible: the first page and the focused page. Since the first page is often the page that originated the entire stack, and since that page is often a Web app (such as when you open many links from Gmail), having this page visible is useful.
+How do we make sure the stack isn’t too cluttered? '''Semantic zooming.''' In the canvas view, the stack is compressed tightly all within the space of the original single page. As you zoom in, the stack magically fans out within that space, revealing more detail, as the view seamlessly transitions to stack view. Initially, you see all the pages in the stack. From there, you can continue to zoom in within stack view, until you have reached the point where the system seamlessly switches to page view.
+Making stack view zoomable (like with the canvas view and the page view) has several benefits. First, large stacks become easier to browse. Instead of slowly flipping through each page until you find the one you want, you can just zoom out a little to get more of an overview of the entire stack, arranged in a way ideal for that zoom level. Imagine if zooming out from page view (or [zooming in on a stack from the canvas) showed you the stack arranged as an easy-to-browse grid, kind of like [http://www.youtube.com/watch?v=7qhDtcbxnak#t=350s zooming in on an album] on the iPad. This need not be the exact visual design, but the point is the same: semantic zooming allows us to make the stack as easy to browse as the overview. With proper information design, we don’t need to introduce a button or gesture in order to show a different view of the stack.
+A second benefit is what happens when you open a new page from a link. Instead of the display zooming out to show the entire stack, we zoom out only enough to show the new page’s placement within the stack. This ensures that the current page is given the maximum screen real-estate, so that it usable even without zooming back in. Similarly, the currently-focused page in the stack should be made usable as soon as the stack view’s zoom level is deep enough such that we see the page and only a few nearby pages.
+'''History Area.''' In order to solve the history area issue along with some others, we first need to redesign the system area. The system area should appear as a strip across the top of the canvas. All system objects should appear there. The history area should be placed in the middle of the system strip, rather than at the corner of the content area. The rest of the space below the system strip is 100% reserved for your content, organized as you wish, without limitation. This solves the page-deletion problem, because we can visualize throwing a page upwards as the history object sliding in from the top of the page while the deleted page gets smaller and is made history, as it were. Throwing a page (or stack or group) from the overview should also be possible (like [http://www.youtube.com/watch?v=l62k87N_93o#t=17 on Android]). The system strip should also include the Command button. If you zoom in on that area of the system strip, you can manage your commands from there. Search should probably also be moved into the Command button as a command.
+This separation of content and system information allows us to present the environment as a clear physical hierarchy. The system strip and the content are are both subsets of everything that belongs to the user. Zooming out from here will show you other users along with other devices on the network. Perhaps zooming out from there will also show you other computers elsewhere.
+Besides cleaning up the system area, we also introduce a new element: a '''status bar''' that appears at  the top whenever we are not in page view. Although this kind of breaks the no–administrative-debris rule, this is a necessity due to the items within it: Command button (as before) at the top left, and '''notifications''' at the right end of the bar. These notifications can come from any open page, both system pages (like the ones that display time, connection, and volume status) and regular pages (such as your messages). When you access one of these items by pulling it down from the top, the item should increase in size and slide down, appearing as a page overlaid on the screen. These pages can also be swiped away just like a page in a stack. Finally, notifications can temporarily appear on the status bar, sliding down the status bar into view if you’re in page view.
+'''Multitasking.''' My hunch is that the main types of multitasking that we should concentrate on are side-by-side tiles and a small floating window in the corner, though research is needed to see if other forms are necessary as well. Each window is a separate viewport onto the environment. Theoretically, two people could use two viewports simultaneously, each viewing a separate user account. What we absolutely do not want is partially-overlapping windows (nor tabs).
+There were several ideas about how we can facilitate multitasking. First, if you drag a page to any edge of the screen, you create a tile on that side displaying that page zoomed in. The other half of the screen will hold another tile displaying whatever zoom level you were at before this action. If your drag a page to a corner instead, you get a floating window in that corner.
+Alternatively, we can take advantage of multitouch to allow you to create a “paradox” for the system: hold down a page in place (at any zoom level) and then perform an action that would have moved the page. For example, tap and hold on the screen in page view with one finger and perform an edge swipe with another finger; the system must then interpret this gesture as displaying the page in one side of the screen while showing you stack view in the other side. Similarly, you can hold a page in place in stack view but then tap on another page. Or, you can tap on two pages at the same time.
+Another possibility is to use a special gesture, such as dragging the screen from the centre outwards with both hands, as if you were ripping the screen into two pieces. This proposal, however, is the least discoverable. Alternatively, we could simply add a New Window command. Such a method would much more discoverable, but would not follow the direct manipulation feel of the other proposals (nor would it be as much fun). Whatever method is chosen in the end, it should be discoverable, quick, consistent with how the system works (especially direct manipulation), and, importantly, fun (so it’s not a mental burden whenever you think about multitasking).
+'''Special Groups.''' As I mentioned briefly in the concept outline, you should be able to install online services such that all their objects automatically appear in you environment. For example, if you install the Google Drive services, all your Drive documents appear as pages automatically synchronized within a special group. We can take this idea further: what if we allowed online services to escape the boundaries of the page? We apps could then manipulate their own groups to display their content in any way they like. So, for example, Flickr could give you not a page, but a whole group that displayed all your photos in a way optimized for photos, together with proper controls or whatever else is desired for that specific task. A music service, on the other hand would organize your music in a wholly different manner. The system could take advantage of this functionality by showing you your history of pages in a manner optimized for viewing your history and restoring old pages. Meanwhile, the main unit of content (pages) from these services would continue to be exposed to the system, allowing  you to search for these pages and to copy them elsewhere. Thus, the system is built with extensibility in mind, allowing you to customize it for different types of content beyond the design of the ZUI.
+===Implementation===
+The following is my best estimation for how this system should be implemented. Ultimately, though, implementation will be up to the programmers. (I hope my description makes sense to the programmers out there.)
+At first, the system should be coded as an application, rather than solely as an operating system. Doing so will allow us to gain as much exposure as possible. The core of the application should be written such that it can also easily be loaded as an entire operating system environment (such as on top of Firefox OS’s kernel). The application should mostly be written as a Web app. It should be available as an [https://marketplace.firefox.com/developers/docs/html5 Open Web App], so that it can be run anywhere Firefox runs: the desktop, Android, Firefox OS. Hopefully, with some extra code, the app should also run in iOS.
+On the filesystem level, each page could automatically be saved as a single file (perhaps <code>.html</code>), a special folder (similar to <code>.app</code>), or an archived folder (similar to OpenDocument). All metadata related to the page, such as location on the canvas and the page’s state, are saved along with it in the filesystem. Groups would simply appear as folders. If a page appears in more than one location, we use a hard link for each instance. Previous versions of each page are also stored, so that you do not lose content when refreshing a page. If the user already has files (such as when running this system as an app), they would appear as pages within the environment. Ultimately, it should be easy for anyone with more direct access to the filesystem to copy pages and to share them with other operating systems.
+From there, one possible goal is to get this system incorporated into Firefox OS (as well as the Firefox browser). Firefox OS’s system of apps could co-exist within our environment: when creating a new page, installed apps will be some of the objects suggested by the Awesome Screen. Moreover, apps could all appear in the canvas as pages. Beyond Firefox (OS), maybe the design could even get incorporated into Open webOS or Chrome OS!
+===The Next Step===
+I, along with countless others, have been frustrated by the inhumane design of most digital environments for far too long. Alas, it is only recently that I developed a more concrete idea of how to fix this mess. For me, there is a moral imperative to try to help the world by giving it a better alternative to the interfaces that confuse and scare people away from computers. The time has come to do something about it.
+In order to make this happen, as many people as possible should see this. Importantly, some of those must be developers with both the ability and the interest in helping me turn this vision into a reality. As I said, my ideal situation is the one in which this interface becomes the one used by Firefox OS. Therefore, I would love to generate interest within Mozilla. There are other projects that would also greatly benefit from this concept, such as Open webOS and Chrome OS. Finally, for any potential employers out there, I am available to work on such a project (and available for a UX jobs as well).
+Let’s make it work!