Archive for July, 2005

TV 2.0 fix this idiot box

Jul 05
31

I’ve had to fix the TV for my grandmother about 10 times over the last two months. These visits have been like an informal usability test. The problem is that technology features are driven by different tv companies and departments. Each contributes to the problem but doesn’t take resolnsibility for the entire user experience.

Here are the core issues with televisions. I believe this is a problem across the whole industry and although the specific examples are from my grandmothers living room I know the issues effect all ages and experience levels.

  1. Turning the TV on should not be complex – Although the TV, VCR, Cable box are made by different manufacturers and each perform different functions they are perceived as a single unit. Because they are a single unit they should have a unified on/off switch. If I turn the VCR on the TV should be on. If I turn the cable box on the TV should be on. There is no common scenario where you don’t want a unified on/off operation.
  2. The TV/Video button should not exist – Many modern TV’s and VCR’s have a button labeled TV/Video. The buttons only purpose seems to be to put the TV into a state where it can not be watched. I believe the intended purpose of the button is to switch between multiple video feeds however if pressed inadvertently on either the TV or the VCR it becomes very difficult to find the permutation of the buttons that will return the TV to a normal state.
  3. VCR’s should not have TV tuners – There may be a reason why VCR’s tend to have built in TV tuners but this actually causes a lot of problems. Even though it’s conceptually possible to watch one show while recording another it’s practically impossible for the typical person. Similar to the TV/Video button the VCR/TV combination must be tuned to a specific channel to ensure that the combination will work. (Usually channel 3 or 4)
  4. Remote Controls are a mess – Each component VCR/TV/Cable Box comes with it’s own remote control. Each one claims it’s a universal remote, but for each one to work it has to be programmed to work with the others. This makes them all not so universal. Each one also includes buttons for every feature you could imagine making them that much harder to use.
  5. Too many cables – There are way to many cables for any novice to figure out. In a simple configuration of Cable, VCR and TV there can be a whole collection of different cables, colors and instructions. Additionally the order that these are added can impact the functionality that is available to the end user.

It’s ridiculous. We can send satellites into space but we can’t figure out how to make TV’s easier to use.

How hard is it to get the heads of Phillips, Toshiba, Sony, Comcast, Direct-TV, Mitsubishi, Hitachi, JVC, Panasonic, Zenith, Pioneer and RCA to agree that there is a serious problem and that the solution to the problem can both improve the customer experience and save millions in support costs?

Top 10 secnarios that should be enabled by these companies:

  • Users can turn on the TV and related electronics with a single button
  • Users can connect any two components with a single wire. Connections should always be transative.
  • Users can combine components from different manufacturers
  • Users can record a show and play it back
  • User can use adjust the volume with the same button regardless of the content being played
  • Users do not need to worry about agreement of TV/Video and channel number to have their electronics work properly.
  • Users can add new electronics without worrying about the order that they are added (Cable->TV->VCR) should behave the same as (Cable -> VCR ->TV)
  • When a user inserts a VCR tape or DVD and hits play the TV should display the video regardless of the previous mode of the TV/Cablebox.
  • If I add stereo equipment, DVR or other components to my TV I shouldn’t have to re-program my volume controls or other settings. Adding equipment should be plug and play

    • I should be able to change the settings and correct problems for my grandmother remotely.

    Posted in Misc., Television | 1 Comment »

    Vod Casting – video on demand

    Jul 05
    25

    Many people have now heard of the term PodCasting but broadcasting audio to your iPod is just the beginning. The next wave of content will be brought to your TV, on demand. The new underground word of the day is VOD-casting the VOD stands for Video on demand and in the next 5 years it stands to change the way TV networks oporate.

    Traditionally cable operators and station owners have to be convinced that there is enough interest in a particular show to make the show worth having on the air. TV networks rutinly cancel shows, because the interest levels aren’t high enough. In today’s world the number of shows is limited to a set of channels and networks.

    If I’m an independent producer who wants to create a witty sitcom I need to get the nod from a major network to have a chance of any viewership. If I’m Garth making Wayne’s World in my basement and I’m fortunate enough to get air-time on my public access channel I have no way to have my message heard around the world.

    Vod-casting can change all that. Vodcasting takes power away from show programmers and puts it in the hands of the people. Any one can make a TV show with a world-wide audience.

    Vod-casting works by publishing a TV show online with an RSS feed. The feed document describes the show and the location of the video file online. Anyone with a website can publish a show. The missing piece that will soon be available is the aggregater, or player. For music and podcasting this was Apple’s iTunes. The logical partner for TV content would be Tivo. There is an opportunity that won’t last long for Tivo to take the lead and allow people to view Vod-cast content directly on their TV. This is the missing piece that can make traditional networks change the way they think about programming content.

    Posted in Prediction, Television | No Comments »

    WYCSSINWYG – How I hate HTML and its ugly sister CSS

    Jul 05
    21

    The tragic story of HTML

    HTML started off as a simple markup for text. It was really basic way to do add a little bit for formatting to what was at the time a text only web. The tags where simple: links, text, bold, italic. Then there was some layout tags left, right, center. Then more layout tags, table, div, span and font. Pretty soon HTML was being used to represent the graphical visions of designers. On top of this we layered all the tools that developers want to build web applications, and as a final touch we added CSS and XML to abstract the look and feel as well as the data from the document.

    If you look at the source of a webpage today it’s very difficult to state what parts are graphical elements, what parts are content and what parts are data driven. It’s all mixed in together.
    A typical HTML document it’s a complete mess. Since HTML can be edited by hand there are many conventions and many correct ways to implement the same design. At the same time there are many ways that may appear to be correct in one browser but will completely fail on another browser. HTML is inefficient to write, all browsers have subtle interpretation issues, there is always a multi-browser and platform testing issue. What you see is never what you get (WYSINWYG).

    • Raw HTML can define text as well as layout in the same line – This makes it hard to internationalize or translate. How do you know that if you change the text you’re not inadvertently changing the layout.
    • Raw CSS can define layout but it can also describe Code like interactions such as hovering, hiding and repositioning elements dynamically.
    • Raw JavaScript can manipulate page elements but it is also often used to fetch and update data sections and display text.

    If we wanted to design a modern web-browser without the confusion and history of HTML limitations it would be broken up into four proper parts.

    1. Text
    2. Data
    3. Layout
    4. Code

    1. Text – The text part would contain a list of text blocks. Each block would be a string of text with optional number/letter style tags. <1> <2> <3> within the text. A document could have any number of text sections and these text sections could have descriptive names such as title, description, introduction, etc. These descriptive names would be optionally used by the code or layout section to be described later.

    2. Data – The data part would contain a list of data blocks. The data block would either be in-line like XML or would refer to an external document. External data would update dynamically and could trigger events that could be used in the code section.

    3. Layout – The layout portion of a document would contain just layout, it would contain, sizing information, position and orientation, accessibility keys and alternative layouts for alternative size devices. It would apply colors, fonts and attributes to the tags within both the text and data sections. Images would be treated as layout elements but descriptive text would stay in the text section. Links, buttons and other elements could also be defined in the layout but any text or labels would continue to stay in the text section.

    4. Code – The code section would be the glue that could tie these sections together. The code section would dynamically change layout, request updated data and change one text block for another.

    This approach allows you to separate the page technologies by job function. A developer doesn’t have to concern himself with layout and look and feel issues. A graphic designer can make the site look cool and not worry about the text. An international translator can translate the text without worrying that this will impact the code or the layout.

    The text section is where most writers would enter content, it’s where bloggers would put their text, it’s where lawyers would enter notes and it’s where web site owners could make text changes.

    The data section is where database administrators could enter data or SQL queries.

    The layout section is where a graphic designer could add a cool look and feel elements.

    The code section is where a developer could wire it all together.

    By separating the concepts you allow better tools for each one.
    -Internationalization tools would optimize the tools that deal with text
    - Accessibility tools would read the text and layout without the graphical aspects of the layout.
    - Layout tools would allow you to create rich graphics and presentation allowing you to absolutely position elements where you want them.

    Template Template Templates
    Here’s where it gets really cool. A template can be any combination of the 4 core elements with one or more elements being dynamic. For example if you have a design with text being dynamic and layout, data code being part of the template then you have a typical blogging template. If you keep the Text, Data and Code but change the layout you have a presentation template suitable for creating applications for a cell phone or TV. If you change the text but keep everything else you have an international version.

    Tools Tools Tools
    Any new approach has to begin with WYSIWYG. This means that the tools have to be visual. Designers want to be able to design it on the screen and have it show up the same way. This means that the language and schema of the markup is second chair to the tool that creates it. The quality of the design rests more with the designers tools then the schema that creates it. A great schema with terrible design tool yields terrible designs. A great design tool with a terrible back-end schema leads to version 2.0 where you fix the back-end. ;)

    Posted in Browsers, HTML/CSS | 9 Comments »

    Google’s Web Browser

    Jul 05
    18

    Is Google building a web browser?
    I’d bet on it.

    Google, our friendly search engine giant is very likely taking a look at developing their own web-browser. Some may say that building a web browser is a great way to waste millions of dollars but for Google it’s a strategic necessity in order to continue to deliver the best of breed in web-based applications.

    Motivation – Google has started off with a core searching platform and is expanding this platform to include content publishing (blogger), email (Gmail), discussion groups (Google groups), photos and imaging (Picasa), mapping (keyhole/maps), video and more. Each of these technologies has extended what people think of as a ‘web-application.’ These products have pushed the bounds of what is possible with a modern web-browser. In fact anyone familiar with the technical hurdles needed to achieve some of the effects knows that most of these technologies needs to be coded separately for each web-browser and that many of them are very fragile. Google would love a robust web-application platform that could be used to build robust and dynamic web applications.

    Competition – There are two major players in the browser space that could provide such a platform, Microsoft Internet Explorer and Mozilla/FireFox. In the short term neither of these web-platforms allows for the richness that Google wants to achieve, and neither one is on a path to add it. Microsoft’s web platform doesn’t exist on operating systems other then Microsoft. That leaves FireFox. FireFox is a good foundation for HTML rendering and CSS but it suffers the history of HTML and some of the drawbacks of standards compliance. Don’t get me wrong, I think standards are great I just think that the current state of HTML, CSS, XML, XSL, XHTML, DHTML, and JavaScript is such a mess that it would be better to start with a clean slate then to try to get it to all mesh together.

    Unique perspective – Google has a global audience that is looking for leadership in user experience. Google could keep adding features and figuring out ways to make their applications work with all browsers but it turns out to be a large developer effort.

    Consider an alternative. Imagine if Google decided to use the FireFox as a code base for a new browser. One that’s not based on HTML but on it’s own invention for creating layout adding text and data and mixing it with server/client interaction. Google could convert it’s internal sites to support the new technology and support for HTML would preserve compatibility with the millions of existing sites. If you could have a rich-client email experience by going to a website then the idea of downloading and installing software seems arcane.

    Now consider this. If Google does creates a new browser that’s not based on HTML it can be designed in such a way that doorway pages, hidden text, click forging and other search manipulation is much more difficult to create and easier to detect.

    The pieces are all coming into place for such a power play. In addition rumors seem to indicate that such a browser team may be forming in Kirkland, WA, just out of earshot from Microsoft.

    Google’s to do list:
    Search portal, check.
    Email application, check.
    File searching, check.
    Web Publishing, check.
    Imaging and Photos, check.
    Calendar – to do.
    Web-browser – to do.

    Disclosure, I own Google stock.

    Posted in Browsers, Google | No Comments »

    U-turn, UI turn

    Jul 05
    18

    I was driving this morning and I got lost. I took a wrong exit and started going down a street. I knew I was going the wrong way and I was pretty certain I wanted to turn around. As I pulled up to a stop light the sign next to the light clearly told me that I was not allowed to make a U-turn. I’ve probably passed similar signs hundreds or even thousands of times, but this time I stopped and thought about it.

    A traffic designer probably realized:

    1. Drivers might get lost and need to make a U-turn
    2. Some drivers would want to make the U-turn at this exact location
    3. A car doing a U-turn at this location could be dangerous or disruptive to traffic

    The traffic designer decided that the solution to the problem is a no U-turn sign. But what they didn’t realize is that this doesn’t solve the actual problem. I still want to make the U-turn and the sign is completely useless to my specific desire to turn around.

    Imagine a computer parallel:

    Now imagine if a couple signs that could have been useful:

    • U-turn up ahead
    • Exit on right to return to Rt 3
    • Please U-turn on side streets only
    • Rotary ahead
    • U-turn only on green arrow
    • Etc. Etc.

    Just a friendly reminder to anyone writing error messages and screen text. It’s not what you can’t do it’s how to get it done that counts.

    Posted in User Interface | No Comments »

    Faster Numerical Entry

    Jul 05
    13

    People enter numbers into computers all the time. Most keyboard even have two numeric pads, one on the right and one above the keys. It interesting to note that the number-pad has the opposite orientation then a telephone number pad but that’s a whole separate post.

    I started thinking about numerical entry and if there is a way to make it faster. I started thinking that the current design offers a fairly uniform distribution of numbers. It’s just as easy to enter the number 102 as it is to enter 100, however in practice I would guess that the number 100 is entered far more often.

    I came up with an alternative keyboard design that I believe would be much faster for entering a lot of numbers. This type of keyboard would best be suited for a physical calculator but it does seem to work for on-screen use as well.

    The keys are arranged as follows:


    The added keys for 100, 200, 300 etc make it really easy to enter units but what’s interesting is how the two sides can interact. The value that is shown as a result is equal to sum of the independent sides of the keyboard. For example if you click “1000″ on the left and enter “5″ “0″ on the left you’ll have 1,050. If you enter “100″ on the left and click “100″ again it will add another 100 to your total giving you 200. If you want to enter “1500″ you could either enter “1000″ “500″ or you could use the older slower method and do “1″ “5″ “0″ “0″.

    Some initial testing seems to show that this is faster for entering long sets of numbers.

    Posted in User Interface, Windows | No Comments »

    Art of Program Managment

    Jul 05
    11

    My former mentor and co-worker, Scott Berkun, has written a great book on program managment. The art of program managment. The book covers a lot of topics including: Ideas and what to do with them, writing specifications, decision making, leadership and managment.

    Scott’s a great writer and has a lot of experience as a program manager. It’s worth a look.

    Tags:
    Posted in Uncategorized | No Comments »

    Why is making something simple so complex?

    Jul 05
    11

    It’s ironic that making something complex is far easier then making something simple. How could this be? Here are some common and not so common things to consider.

    • Developed by me, used by others. – The most common problem I see are companies that design and develop tools for people other then themselves. If you don’t plan to use the software yourself why would someone else use it? Designing software without first hand experience requires you to leap into someone else’s head. The developer or program manager designs software in a manner that fits his own mental model and doesn’t always verify that this model is the same as his customers. Whenever possible try to be your own customer. Use your own products daily to serve a job function that’s as similar as possible to your actual customers.
    • 80% vs. 20% – Most applications have one core piece of functionality that accounts for 80% of how the application is used. However this critical piece accounts for just 20% of the code. Teams spend a disproportionate amount of time designing and developing the non-critical components to satisfy edge conditions. At the start of your project phases determine what you feel are your critical features. Never let a non-critical feature negativity impact the interface flow and simplicity of your critical UI.
    • Consistency takes more time – To make something simple you need a clean and consistent model across the entire application. To create such a model and ensure that it’s consistent throughout takes a lot more time then having each feature perform independent to all the others. If the project is large or will take a long time make sure everyone is sharing specs and actually reading them. If there are shared concepts there can be shared user interface components as well.
    • Features Creep – More features don’t always make a product better. Many sales and marketing managers feel that adding features to a product will always help you sell more of your product. There is a constant pressure to add more features. You will rarely hear, “Figure out a way to get rid of features X, Y and Z or fold them into existing functionality.” Instead of features concentrate on scenarios. Here’s the difference:
  • Feature – Allow users to print their photos
  • Scenario – Allow users to share their photos with friends and family
    A good scenario helps your product tell a story. A feature is just a page in that story.
    • Out of time – I’ve seen this on a few projects where the team spends a lot of time designing the back-end technology and at the end of the project they ask to “slap on an interface.” Designing software for the user can’t be an after thought. Imagine a construction company building the plumbing and electrical work for a high rise and then asking an architect to throw on a facade.

    Designing simple software doesn’t have to be hard but it does take time and planning. People make mistakes and to make software “friendly” we have to teach the software how to be more forgiving to our mistakes.

    Posted in User Interface | No Comments »