Google Search

Showing posts with label Thoughts. Show all posts
Showing posts with label Thoughts. Show all posts

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:

Resolution

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.

Technology

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.

Saturday, June 11, 2011

Web Development

I recently started developing applications for the Chrome browser. This is as simple as developing any other web application, except I had no experience developing web application before.

In this post I will share my impressions of web development and finally share my ideas of next generation web development.

I had to learn JavaScript to a level that would allow me to write complex, object-oriented pieces of code. I didn't really bother with HTML5 and CSS3 - whenever I needed something I could easily find it somewhere on the web (mostly in www.w3schools.com). But scripting is different. You can't just not remember the basics, so I had to learn it on the go.

My impressions of JavaScript is that it is not as good as most compiled languages (like C, C++, C# and even Java). It is not type-safe, and it's object-oriented syntax is horrifying. In addition it lacks data structures like lists and hashtables (or dictionaries), so you need to use alternatives.

Friday, June 10, 2011

Thinking of moving to Linux

Well this thought has been around for a very long time now.
I started to learn to work with Linux a long while ago, in my first professional job. Then was also the time I got to know the world of open source software.
I've been following the development in the Linux world, and every now and then downloaded the latest ISO of some distributions for a test drive. In the end I never gave up Windows. I felt that Linux just could not give me all the tools I need for my everyday tasks.


When I started using a Media Center in the living room, I chose XBMC over Ubuntu Linux. It did a pretty good job and was enough for what I needed.

The Ubuntu distribution was a good Linux choice for a long time, but only now, in version 11.04 it feels like there is nothing I want to do with it and can't.

I always prefer open source software over closed source software and commercial software, with the exception of my Home Windows (Vista 64) which I bought with me PC almost 4 years ago, and Office 2007 Home and Student that I bought for my girlfriend while she was a student (in a great student discount).
Every now and then I review all of the installed programs I have and see which have a Linux version of a descent Linux alternative.

Thursday, March 4, 2010

Year 2048

In just less than 38 years from now, year 2048. I’ll be 65 years old. The world will be filled with slogans like “The real Y2K” spread by techies.

This wasn’t possible on Y1K. Actually, it only became possible in the last several decades. A century, if considering some really old inventions.

I said “the world will be filled with slogans”, because I’m not sure that saying “the internet will be filled with slogans” will be correct. The internet had evolved a lot in the last decade. From slow dial-up (yes, it was like that in late 90’s and early 2000) to 100mib constant connection, from home PCs to our cellular phones and PDAs. From simple websites with slowly loading GIFs, line by line, to advanced, interactive sites, filled with animation and streaming video.

This all made me think what it would all look like in 38 years. I sometimes feel that when looking ahead in the short term, to the next year or two, it is very hard to think that great revolutions might occur. Thinking of bureaucracy of different authorities, things always seem to get delayed. But in the long term, things does happen very fast indeed. Dazzling fast.

I know there are people working on shaping the next generation of the internet. I just wonder how far we can really imagine in such an exponential world.

Sunday, July 26, 2009

Writing Quality Software – Quality Assurance

One must not underestimate the necessity of the QA team.
Quality Assurance (QA), the guys that test the software designed by the engineers and written by the developers. Their mission is to make sure that the software does what it needs to do, and do it well. They are also the first users of the software so they have the best review and criticism about the visual design and usability.
A developer needs to learn to listen to the QA team notes. The QA team, on the other hand, must learn how to note.
In order to really understand this, lets check things more thoroughly:
First of all, the role of the QA team versus the role of the development team in terms of software operability:
No QA team – Bad software; No development team – No software.
That said, we now need understand that the two teams must work together in order to create good software.

Thursday, May 28, 2009

How can Wikipedia improve its content reliability

Wikipedia is a very common online encyclopedia, built and managed in the form of a wiki, which means anyone can modify its values.

While this promises many writers, editors and critics, thus up-to-date content all the time, it also introduces great unreliability, as you can’t trust anyone who had written anything.

While even “Wikipedia founder admits there are serious quality problems”, I figured something can be done to improved the reliability and quality of the content.

So here is my idea: Wikipedia should introduce a “Content Reliability Factor” that will be visible, sticking out on the top of each page. This factor will be on a scale (say, from 1 to 10), and will allow the reader to know how reliable the information on this page is.

In order to calculate the reliability factor, Wikipedia should introduce “Fact Markup”, to specify “Fact Fields”. Items that represent clear, hard facts, preferably numbers, will be marked using this markup.

There will be different types of fact fields: Absolute numeric fact fields (usually used for scientific articles), Usually climbing numeric fact fields (say, number of children of someone), Citations, etc.

Readers that come across  fact fields would then be able to rate the correctness of each fact field, and/or the entire article. Some users will be granted higher reliability factor for some values or categories, and their vote will have higher influence of the calculated result. (Of course, some articles will be blocked for such changes, for the same reasons some articles are blocked for public editing today).

Now to the really good part: When ever someone that is not trusted in a certain value or category, changes a fact field, the reliability factor for that fact field decreases. The amount of decrease depends on the type of that fact field – say, for usually climbing numbers, a decrease of that number would result in a very large decrease of that field’s reliability factor, while an increase would result in a smaller decrease of that reliability factor.

In the article history, the reliability factor will be stated next to each version. In addition, the highest ever reliability factor will be stated next to the current reliability factor on the top of the page, and will link to the relevant version of the article.

So all in all, while this idea does not solve the problem completely, and surely does not free us from the need of human approval for the content, it will allow to make better decisions regarding the given content.

P.S., There are many other methods that can be integrated into such a system that will assist with its automation. Maybe I will discuss those some other time.

Tuesday, April 28, 2009

What can the government of Israel do to solve the water crisis

Israel suffers greatly from lack of water.

This is the case for many years now, and from one year to another the government is doing more and more to solve it. By "doing more and more" I mean pass on the blame and the responsibility to the citizens.

Now they have a big campaign featuring all greatest Israeli celebrities, telling us to save water; telling that we must stop watering our gardens; asking to shower less. Before we'll know it they'll limit our tap water drinking.

This is, of course, useless and idiotic. It won't help even a tiny bit. This is the same as doing micro-optimization to a monkey-sort algorithm. This is because the reason to this water crisis lies mainly on the fact that the population growing while the amount of water in our reservoirs stays the same (in the good case) or lowers (in the bad, current, case).