Google Search

Tuesday, September 18, 2012

Desiging a website for TV browsing

It seems to me that there is a future for TV based web browsing, as more and more TV sets are getting internet connection, more people are starting to use HTPC systems and Media Centers, and even the big companies that provide cable TV start to introduce set-top boxes with internet support.

Even computer and internet companies like Google and Apple create their own TV set-top-boxes Google-TV and Apple-TV.

The only thing left websites. Most websites today are not ready for TV browsing. Actually, most websites today are not ready for the much wider used smartphone and tablet browsers.

As a website programmer I found out most small to medium size companies just don't want to invest money in such designs, that provide a much different user experience than a regular desktop website. But this is another story to discuss.

So, who needs a website designed for TV, anyway?

In my opinion, in the perfect world, all websites would have had a desktop version, a mobile version and a TV version.

Sine the world is less than perfect, and all the designs cost money, it means that only a small portion of the web can build a TV enabled website. This includes:

  • Big companies with a lot of resources.
  • Companies that could lose potential paying customers (most online shopping platforms).
  • Websites that have TV related content.
  • Search engines.
  • Websites that provide video content.
  • Blogs and Forums.

Each website should have its own unique design for TV browsing, but they all should follow some rules of thumb regarding resolution and scale, font sizes, remote-control based navigation, and text input.

There are some guidelines (not many) available online for the above list, but I'll give my own two cents:


Most TV screens that have integrated browsers, or that are connected to an HTPC or Media Center of some kind, probably support 1920x1080 resolution, but you can also find other resolutions such as 1366x768 (second most selling TV sets resolution after Full HD) and some other more bizarre resolutions and aspect-ratios such as 1680x1050, 1280x1080, 2560x1080, 852x480, etc.

So there are a lot to design for, but I think designing for the two most common resolutions (1920x1080 and 1366x768) is the best idea, especially when keeping the design flexible for wider screens or more square screens.

Font Size and Text

Keep in mind that people are watching their TV from about 3 meters far, corresponding to somewhere between about 20-degree to 40-degree viewing angle. This means (and I'll take a 30-degree angle here for easy computations) 0.0278 degrees per pixel.

Screen text is readable at about 0.5 degrees view angle, which means that the smallest text should be at least 20 pixels high.

Use small text sparingly in the website and only where really needed (for instance - a plot of a TV episode). Prefer much bigger text with as few words as possible on headings, buttons and links, instead.

Remote Control Navigation

People who uses TV browsing don't want to hold a keyboard in their hand, and will use a simple remote control most of the time. Design the web site so it fits a remote control navigation. This means, easy to understand and navigate menus, with fewer clicks as possible.

For instance, you can use the Master-Detail approach, where there is a main menu on the left side of the screen (Master), and for each selected item the main area switches to detailed display, or a sub-menu (Detail). If you decide that there are several levels of menus, keep the last level visible and hide the previous levels. But make sure to keep "breadcrumbs" listed above, and make them navigation links.

Another approach, better for long icon-based lists is a grid. Again, keep breadcrumbs visible and navigational, since the grid is hidden and replaced with content whenever an icon is selected.

Use the "Back" button correctly - make it go back one step in the breadcrumbs list.

Remember that remote control navigation is slower than keyboard navigation due to IR transmission times, so make sure to keep each action with the minimum essential clicks.

Text Input

Most TV Remote controls don't have the option to input text, but do have the option to input digits, so design the website so if any input is required, prefer input of numerical values. I know this rule will most like only apply for dates, IDs and prices, but if you can only handle with those, the better.

Most sites that need text input can't. So if the TV itself doesn't offer an on-screen keyboard, it's up to the website itself to offer one. Have a button visible next to each text field (it can and should be visible only when the text field is focused) that offers an on-screen keyboard.

Use the local-storage mechanism in HTML5 (or any other mechanism you wish) to keep track of last inputs (in case the TV browser won't do it for you) to save the user from re-entering the text again.


Unfortunately, there is no current standard, not a standard "de-facto" for remote control usage, and each and every TV browser is using it's own system. Currently you can find the Google TV, Meego TV Browser, DirecTV web browser, Samsung TV web browser, Zinc, Boxee and some others, each with API of its own (links refer to the control API).

Plan your website's technology in a way it matches the target audience by the technology they use (you can do a market research for that) or just write (or find) a wrapper for the remote control events such that hides the complexity of figuring out which browser is used and to what events you should register.

Friday, May 18, 2012

Custom Resizable Windows in WPF and Winforms

The following post is relevant for both WPF and Winforms projects, wishing to create custom looking windows that can be dragged and resized from all directions (or specific ones).
We will need to use some native Win32 APIs. So first we need to declare the SendMessage function:
static extern IntPtr SendMessage(IntPtr hWnd, UInt32 Msg, Int32 wParam, Int32 lParam);
We will use that function with the window handle, passing WM_NCLBUTTONDOWN (0x00A1) as message. The trick is to pass the correct wParam and lParams so Windows will think we're dragging the window or resizing it through any of it's resizing handles:
enum WindowHandles
    HTCAPTION = 2,
    HTLEFT = 10,
    HTRIGHT = 11,
    HTTOP = 12,
    HTTOPLEFT = 13,
    HTTOPRIGHT = 14,
    HTBOTTOM = 15,
There are actually more handles, for the client area, close button, minimize and maximize buttons, etc. They are all listed in the WM_NCHITTEST message page on MSDN. I only listed the handles relevant to our case.
We will be tricking Windows by simulating a mouse down event on a specific drag-handle. But since we know that the drag starts by listening to mouse-down even, we first need to tell Windows that the mouse button is not down anymore. To do this we will also need the ReleaseCapture function:
public static extern bool ReleaseCapture();
Now all there's left to do is to call the SendMessage the mouse button is down for each of our custom drag-handles with the native window handle (HWnd):
const int WM_NCLBUTTONDOWN = 0x00A1;

void RegisterCustomBorderEvents()
    // do similar things for all borders and for the caption.
    LeftBorder.MouseDown += OnLeftBorderMouseDown;

void OnLeftBorderMouseDown (object sender, EventArgs e)
    SendMessage(windowHandle, WM_NCLBUTTONDOWN, (uint)WindowHandles.HTLeft, 0);

WPF Notes

In WPF you will need to use the interop API in order to get the window handle:

IntPtr windowHandle = new WindowInteropHelper(myWindow).Handle;
Where myWindow is the window you want to drag. If you implement this in the window code behind, just pass this.

Also in WPF there are built in methods in the Window level for dragging the window (DragMove) and in the UIElement level for releasing the mouse capture (ReleaseMouseCapture). You may use them instead of the PInvoke versions where possible.