More Unity TV Mockups

As promised in my previous post about my Unity Phone Mockups, here’s a look at the TV mockups I’ve been playing with over the last week, along with the reasons behind some of the designs.  Links to the source files for these mockups, as well as the mockups by other community contributors, can be found on this wiki page.

These aren’t as innovative as my phone mockups, partly because I didn’t have much of a reference to start from like I did with IOS and Android for phones.  I have a DVR from my cable company, but no HTPC or other media center software.

The TV frame and choice of movie (Big Buck Bunny) came from Alan Bell’s template.  I added a remote control to that, and added buttons as I found a need for them.  In the mockups, I’ve highlighted the buttons you would use to interact with the given screen.

The basic concept was to overlay the Unity components when the user presses the Circle-of-Friends button on the remote, but to otherwise leave whatever they are watching full screen.  On this mockup I used applications in the Launcher, and pressing the CoF would put the focus on them the same way Alt-F1 does on the desktop.  You could then navigate through them using the arrow buttons on the remote, pressing OK to make your selection.

In this alternate mockup, I replaced the applications with Unity lenses, which I think makes more sense for a TV, since you will more often than not be interested in finding content, not selecting which application to run.  Luckily Unity already supports both, so this is just a matter of what the default initial configuration should be, after that the user can put whatever they want in the Launcher.

For opening the dash I envision being able to double-tap the CoF button (or selecting a Lens).  In fact, I would like to have this on desktop Unity, since I want quick access to the Launcher more often than I want the Dash.  Once the Dash is open, you would use the remote’s arrow buttons to navigate through the items listed, again pressing OK to make your selection.

For accessing the Dash’s filters, I added the “context menu” button to the remote which, when pressed while on the Dash screen, will open the filter sidebar, letting you navigate through the filtering options using the remote’s arrows.  Pressing the context menu button again would collapse the filter sidebar and return arrow navigation to the results table.

Likewise I added a Search button to the remote to send focus to the Dash’s search field and activate the on-screen keyboard.  Text input from a remote like this will be cumbersome (unless we come up with a monstrosity of a remote like this), so we’ll want to avoid the need for this as much as possible.  But since the Dash is highly search-focused, I felt that there needed to be a mockup for this aspect.

This is a screenshot of Shotwell taken from my laptop and scaled to fit a resolution it might be at on a TV screen.  I did this to demonstrate how an existing desktop app might look and work without modification on a 10 foot interface.  Here again I added a new button to the remote, which is a kind of next/last panel or, more accurately, the tab key on a desktop keyboard.  This lets you navigate through widgets and panels on a traditional application like you can using the tab key on a desktop.

I think with some small enhancements to GTK and QT, we can allow application developers to make navigating apps this way easier.  Alternately, a new library similar to uTouch could act as an interface between remote control input and applications.

Someone pointed me to YouTube’s LeanBack interface, an HTML5 webapp designed for 10 foot displays.  This is a very promising way to deliver applications and contents to internet connected TVs, especially if we ship with a fully functional, HTML5 supporting web browser optimized for control with a remote.

Finally I wanted to show off Media Explorer, a media center application built on the same Gnome technologies as the rest of the Ubuntu desktop.

Feedback

Just like I did in my last post, I’d like to solicit discussion and feedback on these mockups, and also ask what other scenarios/mockups you would like to see.  You can either leave comments here, or join the live conversation in #ubuntu-tv on Freenode.

This entry was posted in OpenSource, Programming, Work and tagged , , , , . Bookmark the permalink.

12 Responses to More Unity TV Mockups

  1. Jon says:

    Try Boxee for more inspiration, probably one of the most polished HTPC interfaces out there (also easy to install and play around, and works with a mouse unlike xbmc)

  2. Rusty says:

    I have yet to see any good explanation for anything in the unity top bar being on the TV screen. I’m not saying that the information may not be good to have, just that it doesn’t need to be there, and a ‘information’ dialog would be a much better place for it to show up.

    An alternative for Boxee would be to do a ‘sudo apt-get install mythtv’ to install and play with mythtv. Try the different themes and see if any of them make sense. There are a few that may seem like a reasonable starting point for a Unity design.

    • Michael Hall says:

      I will try and do some mockups showing how the top panel might be used on a TV. We need to be careful not to fall into the trap of only thinking about video playback when we consider what might be useful and what might not, if video playback is all that we’re going to do then we might as well not do anything since there is already plenty of decent options for that.

  3. Saludos Michael

    Great work, you really get us all into this vision. I remember playing with a samsung smart TV and it came with a remote that had a regular tv keypad on one side and once you turn it you had a full querty keypad for the smart hub. Looks like it would add more input.

    http://www.blogcdn.com/www.engadget.com/media/2011/01/top-samsungqwertyremote1wm.jpg

  4. Megacruiser says:

    Re-using the whole Unity-layout for a TV seems a bit redundant to me. My suggestion is, that the main intention should be to create a Smart-TV, which lets you install single (TV related) apps. Within this approach, one would focus on creating an interface of the Ubuntu Software Centre which is easy to handle with a remote control. And also on an easy way to display the apps which are already installed. I really don’t see the point of reducing the displayed information (for the ‘main button’ interaction) to the apps which fit in the vertical launcher bar. You’ve got to have the commonly used apps (which would be such things as Play TV, Play Bluray, Browse Files, Browse Youtube, and so on …, TV Version of Software Center) immediatly on start-up, respectively immediatly on the main button interaction.

    For me, the main reason to buy such device (i.e. an Ubuntu Smart-TV) would be the availability and easy installability of loads of actively developed TV-related apps. Whereas it possibly should be possible to do other things with it (like having email-, facebook- & twitter-stuff & notifications), one should really focus on those TV-Apps. Maybe making design guidelines, so the user instantly knows what to do when using a new app.

    Another thing (besides the TV spin of Software Centre) would be a TV spin of the system-settings, focusing on totally different things than the current one …

    … and so on. So for me it’s apps, apps, apps, a fast and easy way to start and display them, and a streamlined and unified way of handling them.

    • Michael Hall says:

      While I understand your point about focusing on a Smart-TV interface, rather than Unity, there are two important factors against doing that: 1) There are already plenty of options for Smart-TV interfaces that do a good job, and 2) The whole purpose of Unity was to provide the same user experience across multiple types of devices. I don’t see a point to an Ubuntu powered TV without Unity. If a whole new interface is developed, then why would it matter if it’s Ubuntu or Fedora or Xandros? And at that point, why make a new interface when we already have Myth and XBMC?

      The reason for using Unity across these devices is to give application developers the same UI targets, and to give users the same UI experience. Why make people think about 3 different ways of displaying/viewing notifications? Why give them 3 different ways of finding their files and apps? Why not say to “Put your app’s messages into this indicator API, and it’ll work for your users on desktops, phones and TVs”? Why not say to users “Your application notifications will always exist here, on you desktop, phone and TV”? Make a blue envelope in the top-right corner always mean the same thing, make it always contain the same thing, and make it always accessible the same way.

      Finally, if we focus on “Play TV”, we’re missing the boat. TV is no longer going to be a real-time, constant feed that you tune into. If you want to watch “Lost”, you look for “Lost”, it doesn’t matter whether it’s coming from your cable provider, Netflix or your local files. Same if you’re looking for a Comedy, you don’t care where it’s coming from. My own kids already think like this. They have no concept of tuning in to “what’s on”. What’s on is whatever they want to be on, when they want it to be on. Doesn’t matter to them if it’s live, recorded, or on-demand. More than just “doesn’t matter”, they don’t even consider it.

      • Megacruiser says:

        Thanks for your reply.

        You’re absolutely right about what you say in your last paragraph, that it doesn’t matter where the content comes from, and that the way you’re looking for the content should be the same, no matter where it is from.

        Nevertheless, I’m not so sure if it is the right approach to use the same interface on totally different classes of devices. I think touchscreen-devices, rc-controlled TVs and the good old keyboard&mouse-controlled PC ask for different ways of interaction. Of course it is possible to make an interface that covers all of those devices. But what I’m actually worried about is, that such interface may not be able to utilize the possibilities of the particular device to its full extend.

        And I still think my point about the unified way to access content is valid. It is also valid for the desktop. In Ubuntu, I access my music via Rhythmbox, my documents and videos via Nautilus, my ebooks via Calibre, all of which got their own particular way of displaying my content. Of course I can handle it, but still, I’ve got to learn the way the interface for every single program works …; and currently the dash, while it may have the potential to unify, just adds another layer: when I’m searching my music via the dash, it will bring up rhythmbox, thus showing me two different organisations of my music … (Maybe one can take a look at what the Gnome-Project is about to do with their new applications – Gnome-Documents, Gnome-Musik, Gnome-Contacts, …; I think they’re trying to deal with this exact situation).

  5. Pingback: Links 13/12/2011: Ubuntu at HMV Stores, Ultimate Edition 3.0 Swaps Ubuntu | Techrights

  6. AL says:

    Good ideas.. But to throw a spanner in the works: Are you a user of videogame consoles? I am from time to time, and one of the most tedious elements of the UI of latest gen consoles when using a normal controller is the pace at which people can compose a written message, even one of short length.

    I’m sure this is someting you omitted, perhaps for the sake of practicality; but when opening the dash and the keyboard overlay, type to search on a remote could be very slow – could the numerical keys on the tv remote double up as text keys?

    1(abc) 2 (def) – like a cellphone?

    Example that brought about my suggestion:
    When using an xbox controller on a full size tv, the speed at which the thumb-stick (compare to directional buttons on a tv remote) are able to flick between highlighted characters to type a message is very limiting. 1/abc 2/def could allow a quicker text input partly because this behaviour would be an embedded understanding with mobile tech the way it has been for years, only recently changing to smartphone touch UI and qwerty key support on larger models.

    Of course with a separate keyboard this could easily be overcome as the user can type at full speed as they would on a computer… But (and it is a big one!) … If Canonical is aiming their sights at a wider demographic, i.e. everyone and their mothers who watches tv casually in an armchair, then they might need to stray from the neccessity for a keyboard in all situations. A text input could mean that the user (bearing in mind the supposed demographic lets call them…) VIEWER, could casually sit in the chair without balancing a keyboard and type on the text keys… Predictive results could be generated and speed up the process, but I would feel that it would be a better experience to not have to use arrow keys or a full M/K to type something short, like a quick program search.

    I see the mail indicators, and that’s great – I would feel a lot more comfortable writing on a full keyboard, but I wouldn’t want to put one on my lap, or resort to a slow directional button-based on-screen board everytime I input the simplest string of text.

    This was just a thought, and I am a fan of the work – this was just a minor bit of constructive usability criticism

    -AL

    • Michael Hall says:

      I have a mockup with an onscreen keyboard, but you’re absolutely right that text input is going to be a bad user experience almost any way you do it. I think using Lens filters to narrow the list of items, then just stepping through them with the remove, will likely be a better way of finding something.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>