Wishlist/BigPageWidget

From Openmoko

Revision as of 18:26, 6 November 2007 by Who (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search
Caveat: While I am not an experienced Linux or GTK programmer, I have a great enthusiasm for and interest in mobile interfaces. This specific idea is based on how much of a joy Picsel Viewer is to use on both the Motorola EZX Platform and Palm OS

Contents

Introduction

The BigPage Widget is a component that any OpenMoko application could call upon to handle the display, zooming, scrolling and interaction with pages larger than the screen. In the proposed implementation, the BigPage widget would allow the application to create a 'canvas' of any size that it could render whatever information it desired to. The BigPage widget (placed somewhere on the UI of the application) would then handle the display of the page (or part of the page, depending on zoom level).

To simplify viewing gestures or accelerometer control could be used to zoom, change page, scroll and reposition documents.

Interfaces similar can be seen in Opera Mini, Picsel Viewer and Mobile Safari. In all these applications this kind of UI is essential to the success of the program


Why?

The strongest reasons I believe implementing such a widget makes sense are:

  • Scaling of larger pages to with the ability to quickly zoom in and pan in order to read detailed sections is a very natural way to interat with documents on a small screen. It is similar to the way we work with real paper, so intuitive (looking at an overview of a page and looking closer at the details we might read).
  • Fast zooming and scaling are superior to reformatting webpages or documents that were designed to be viewed at conventional screen sizes - it makes the device more useful.
  • Given the likelihood that this method will be adopted by at least some of the applications that make up the OpenMoko platform it makes sense to have consistency in the fashion in which this kind of interaction is done (especially because to master gestures can take some time)
  • Such a system could be fairly intensive on memory so having a single widget rather than many different implementations of the same idea will reduce memory useage/"dupliction of functionality in memory"
  • It is a desireable feature that many application developers may like to include but be unable to because of lack of experience in writing the necessary graphics code. Making it re-usable and easy to invoke allows cool applications to be written fast, bringing more people to the platform as users and developers
  • It's cool!

Further Explanation

A bigger area to render to

One of the key ideas in BigPage is that an application can render a document at any size it wants. The application developer need not worry about reformating, scaling or anything else. This allows developers to provide users with unfettered rendering of real documents, designed for viewing on a big screen. In business speak, we're making a small device big...

The clearest way I have found to express what is happening is this: The small screen on the mobile device is being used as a window to a larger page. It's as if I've put a big black page with a hole in the centre on my desk and I can easily move around what's underneath so I can see it through the hole. A piture helps here




Wishes warning! This article or section documents one or more OpenMoko Wish List items, the features described here may or may not be implemented in the future.
Personal tools
Caveat: While I am not an experienced Linux or GTK programmer, I have a great enthusiasm for and interest in mobile interfaces. This specific idea is based on how much of a joy Picsel Viewer is to use on both the Motorola EZX Platform and Palm OS

Introduction

The BigPage Widget is a component that any OpenMoko application could call upon to handle the display, zooming, scrolling and interaction with pages larger than the screen. In the proposed implementation, the BigPage widget would allow the application to create a 'canvas' of any size that it could render whatever information it desired to. The BigPage widget (placed somewhere on the UI of the application) would then handle the display of the page (or part of the page, depending on zoom level).

To simplify viewing gestures or accelerometer control could be used to zoom, change page, scroll and reposition documents.

Interfaces similar can be seen in Opera Mini, Picsel Viewer and Mobile Safari. In all these applications this kind of UI is essential to the success of the program


Why?

The strongest reasons I believe implementing such a widget makes sense are:

  • Scaling of larger pages to with the ability to quickly zoom in and pan in order to read detailed sections is a very natural way to interat with documents on a small screen. It is similar to the way we work with real paper, so intuitive (looking at an overview of a page and looking closer at the details we might read).
  • Fast zooming and scaling are superior to reformatting webpages or documents that were designed to be viewed at conventional screen sizes - it makes the device more useful.
  • Given the likelihood that this method will be adopted by at least some of the applications that make up the OpenMoko platform it makes sense to have consistency in the fashion in which this kind of interaction is done (especially because to master gestures can take some time)
  • Such a system could be fairly intensive on memory so having a single widget rather than many different implementations of the same idea will reduce memory useage/"dupliction of functionality in memory"
  • It is a desireable feature that many application developers may like to include but be unable to because of lack of experience in writing the necessary graphics code. Making it re-usable and easy to invoke allows cool applications to be written fast, bringing more people to the platform as users and developers
  • It's cool!

Further Explanation

A bigger area to render to

One of the key ideas in BigPage is that an application can render a document at any size it wants. The application developer need not worry about reformating, scaling or anything else. This allows developers to provide users with unfettered rendering of real documents, designed for viewing on a big screen. In business speak, we're making a small device big...

The clearest way I have found to express what is happening is this: The small screen on the mobile device is being used as a window to a larger page. It's as if I've put a big black page with a hole in the centre on my desk and I can easily move around what's underneath so I can see it through the hole. A piture helps here




Wishes warning! This article or section documents one or more OpenMoko Wish List items, the features described here may or may not be implemented in the future.