MHP

> BTW we are moving to a lighter approach. we like interactive tv java based and are putting in place a project for a lighter middleware for dreambox like STB (liunx based too..) here:

I wonder if you could please consider having the following features in your specification.

* Six coloured buttons available to all end users: red, green, yellow, blue, magenta, orange.

Ideally control units will have all six coloured buttons. However, programmers would be advised to make using LEFT mean magenta and to make using RIGHT mean orange when an application is just using colour selections and not navigation at the same time. So the Java program response for magenta would occur if either the magenta button or the LEFT button were pressed and the Java program response for orange would occur if either the orange button or the RIGHT button were pressed.

* A large white heptagonal button for accessibility features.

* Access to Java mouse events to all end users.

The MHP specification makes access to Java mouse events an option. I feel that this leaves the MHP system underpowered. Having access to Java mouse events to all end users is, I feel, an important consideration for the future of interactive television.

William Overington

24 June 2007

William_Overingtona at 2007-7-12 20:11:36 >

> may i ask why six is better than four?

> with regard to usability, i believe everyone is willing to buy the traditional 4 colored buttons and they'd find weird six

The MHP specification has provision for six coloured buttons and does not specify the colours for any of them. The minimum MHP receiver must use four coloured buttons. Six is an option for implementing an MHP receiver.

Some years ago I produced some designs featuring the accessibility button which I have suggested, as concept illustrations. Those designs did, in fact, include magenta and orange buttons. They are still available on the web and some readers might like to have a look at them.

http://www.users.globalnet.co.uk/~ngo/heptagon.PDF

http://www.users.globalnet.co.uk/~ngo/heptago2.PDF

Six coloured buttons would allow more scope for interactive applications.

> FWIW, we categorize services and experience in these two well different environments:

> TV experience = a silent STB, a public display and a remote control, to browse info and multimedia, light interaction

> PC experience = a supercomputer, a personal display, whatever user interface, to create, manipulate info and media

That categorization cuts off many possibilities for interactive television. If the Java program running in the television could have access to mouse events, then much more would be possible with interactive television. Telesoftware broadcasts could be used to provide interactive distance education across whole continents with no need for any return information link. So why put interactive television into a category which greatly limits the possibilities of using telesoftware to produce spectacular effects? Telesoftware is interactive without the use of any return link. Unfortunately the MHP specification uses a parlance which uses the word interactive for systems which have a telephone line going somewhere, maybe not to the broadcasting computer at all. If you are designing a new system then please consider using a different parlance. The MHP specification uses the term enhanced broadcasting for what is, in fact, a pure telesoftware system, a system which provides interactive television to the end user. What the MHP specification terms an interactive profile could be termed an augmented profile. MHP was developed on a basis of members only with membership at a high cost and membership only open to organizations.

> so these are our mantras about interactive tv:

There are a number stated, one of which is as follows.

> don't slap the PC-centric interfaces (focus, pointer, mouse) on the face of the tv user

There is a fundamental difference between slapping the PC-centric interfaces (focus, pointer, mouse) on the face of the tv user and providing access to mouse events so that some advanced Java programs may use them. Certainly, keep it to buttons for many everyday applications yet please allow application programmers to choose to write a Java program which invites the end user to use mouse events.

In fact, MHP provides for access to Java mouse events, yet only as an option: the minimum system does not have access to mouse events. I feel that that may well lead to most set top boxes not having access to mouse events.

As a compromise it would be possible to make every set top box able to use mouse events if an appropriate hand-held controller were used and then to sell in the shops two types of hand-held controller, one which cannot generate mouse events and one which can generate mouse events.

So, I ask for a reconsideration of this situation please. Decisions made now may well influence the future of interactive television for many years.

Please consider what telesoftware can do and whether your system can use telesoftware to its full potential.

William Overington

26 June 2007

William_Overingtona at 2007-7-12 20:11:36 >

MHP has at the heart of it my telesoftware invention: telesoftware does not use a telephone line at all but works by the unidirectional cyclic broadcasting of software and its selective use by reception-only advanced television systems. MHP calls this enhanced television and then uses the term interactive for systems which use an uplink as well, even though the uplink need not go back to the central broadcasting computer but could go somewhere else entirely, such as, say, a mail-order clothing business in order to process an order. So, in my opinion, the MHP specification, by the parlance which it uses, greatly underestimates the potential interactive capabilities of the one-way broadcasting of software.

The first telesoftware broadcasts used teletext broadcasts, lines of digital information within a few of the unused lines on 625-line analogue television channels. That was because teletext pages were already being broadcast. In fact, I invented telesoftware in the autumn of 1974 before I was aware of the existence of teletext. I had originally thought that separate broadcasting channels would be needed. When I learned of teletext later that year I realized that teletext pages could provide a way of implementing telesoftware broadcasts without needing additional broadcasting channels. Telesoftware was invented as an extension to broadcasting of a theoretical method of function generation for an analogue-hybrid computer where information would be sent unidirectionally by wire to any number of function generators within an analogue-hybrid computer: telesoftware thus came from outside the broadcasting industry. The idea for the analogue-hybrid function generator was based upon an analogue function generator which was in the literature of analogue computing. In that original, if I remember it correctly, an analogue signal, such as, for example, a sine wave was sent continuously along the wire. A second wire carried a sawtooth wave at the same frequency, synchronized as to phase. An analogue computer function generator wishing to compute a value y = sin(x) from a voltage x, x being quasi-static in relation to the sine wave and sawtooth signals , would compare the value of x with the value of the sawtooth wave and then do a ''sample and hold'' on the sine wave when the value of x and the value of the sawtooth signal were the same. Thus the value of y would be linear to sin(x) so scaling y and maybe adding or subtracting a constant to or from it would produce the desired value. I seem to remember reading that that would work well if the frequency of the sine wave and the sawtooth wave were at least one hundred times the frequency of x. In practice this was easily achievable as x would typically be slow-moving.

I never use the word downloading when referring to the gathering of software or data into a set top box from what MHP calls an object carousel. I tend to think in terms of the object carousel as being an example of what I think of as a "telesoftware disc", a slowly rotating read-only disc in the sky. To me, downloading requires first of all an uploaded request. For example, one may download a software package from the web. To me, a set top box does not download software or data from the object carousel because it does not issue an uplink request to the object carousel, I think of the set top box selectively gathering software and data from the object carousel as the object carousel rotates. I feel that this precise distinction of terminology is important. A telesoftware system is different from a system where a central computer sends out information in response to specific uploaded requests.

William Overington

28 June 2007

William_Overingtona at 2007-7-12 20:11:36 >