I was recently at a local CostCo doing a user interview and had to skip lunch beforehand. On the way out I thought I’d grab a hotdog to curb my hunger. After devouring my meal I went to throw away my trash and I was confronted with a situation similar to what’s shown in the image below.

How clever, I thought. There’s some nice color-coding, instructions and silhouettes to help me map what items need to be discarded where. This should be a piece of cake, but then things broke down.

I was overwhelmed by the feeling I might make a wrong decision and put something in the wrong bin. I went to throw something in one bin, then changed my mind or double-checked once I realized there weren’t others of that item in there. Eventually, I think I put everything in its right place, but I could see others got frustrated and just dumped everything in one bin.

This experience made me think about whether or not the concepts used to help patrons map their trash to the appropriate bins could have been pushed further. I thought the color-coding and silhouettes were key components, but they only got me half way there in terms of reaching my goal. It also didn’t help that I was also in a rush.

In fact, what immediately came to mind was a toy I’m sure we all remember from our childhood; shape sorters.

So… What if the paper plates, cups, silverware, napkins were all color-coded to match the bins? For further enforcement, shapes could also be used to make a connection to the trash and the bins. For me, this would make things easier to understand and may even bring a degree of playfulness. Here’s my artistic rendition:

Would it be more expensive to make this solution happen over what’s currently in place? I’m sure it is. However, how expensive is it for people to sort out misplaced trash later down the line? How much is it to print out those banners of instructions? Is the savings worth the additional “strain” on customers?

In the end, I’m sure something like this might be cost prohibitive and hard to maintain, but I know at the time a system like this may have helped me out a bit. I really think using the silhouettes provided the strongest recognition for me, but it didn’t solve the problem of materials.

For all I know there could already be a solution to this. I thought posting my thought process here might be worth while considering I seem to be having a lot of things like this popping into my mind. We’ll see if I can make a habit of it.

A while ago, like so many others, I started using Instagram as a quick and easy way to capture and share photos I took. The functionality was great; quick and simple to use.

With the posting to Twitter, Flickr, Facebook, etc. it felt like the photo only existed for those who initially saw the link or image. This seemed appropriate since these photos were in fact a moment in time with an expiration.

Eventually, I wanted to share my Instagrams with others who weren’t following me and after I had posted them. I wanted a gallery.

Nothing really existed for that, so i thought as a little exercise to continue learning jQuery I’d try and make a gallery for myself. Initially, I thought I could just use an Instagram API, if it existed, which it doesn’t. Eventually, I settled on just using the Flickr API to pull any Instagrams I had posted there.

This solution seemed the quickest and easiest way to pull off what I wanted. Yes, it’s dependent on me posting to Flickr and the fact that Instagram automatically tags images with “Instagram”, but it works.

The result is a site called GramJunction.com. Initially this was just for me, but I eventually added the ability for anyone to create their own gallery by entering the a Flickr username they post to from Instagram. For example, my photos can be seen at http://gramjunction.com/#mostlyalso.

I definitely learned more about jQuery and using the Flickr API. It was a fun little project and it’s nice to see that others have enjoyed the site. I’ve also seen some really interesting stats in the site analytics showing how much Instagram is being used all over the world.

Give the site a try at http://gramjunction.com.

Once my Google TV arrived I went to set it up thinking it would take no time at all. Just hook it up to my TV and that’s it, right? Well, it was a bit more complicated than that. The first time I set it up I kind of half-assed it cause I just wanted to start messing with it. I accomplished that and then kinda forgot about it for a day or so.

My attention turned back to the Google TV after I had heard about the iPhone app and some of the other interesting things people were saying about it. This time I reworked my entire stereo, TV and set top box setup around the Google TV.

After all that there were some things that I really liked and other that were pretty flawed. I’m not going to get into those things in this post, but one of those things that caught my interest was designing/developing web apps optimized for TV.

I’ve been interested in designing apps for TV for a while and in many ways there are similar things that parallel designing for mobile devices, i.e. screen size, inputs, context, etc. As far as development goes, I started thinking about why I got this Google TV in the first place; to develop using AIR for Android.

However, there were some really great examples Google put out of apps built using HTML/CSS/JS. I decided to make a TV-optimized web app using that route, not only to learn how to design for large screens, but to also give myself a project to get into more jQuery.

As far as what app to build, I decided on making a Dribbble app because Tyler Gaw had already put together a great jQuery plugin for the Dribbble API called Jribbble. Using that plugin I just started throwing stuff together and designing as I went. Google put together some great documentation for both designing and developing web apps for GoogleTV that I kept referring back to.

After some random hours spent in my free time spread out over a few weeks I finally had something to release. I named the app “Jumbbbotron” and it works on both GoogleTV and WebKit browsers. I haven’t tried on other things like XBox, Wii or Boxee. It looks great on the iPad and other tablets too, although there are some interactions and bugs to work out on that front.

While building Jumbbbotron I was also able to incorporate some key things that helped the TV-optimized experience:

1. Directional keypad navigation
2. TV-optimized design
3. Using the Play/Pause button to start/stop “Slideshow Mode” (or the “P” key if your in a desktop browser)
4. Horizontal scrolling instead of vertical scrolling
5. Using local storage for preferences

Overall, I felt I met my goal of learning more about designing for TV and more about jQuery to create a nice TV-optimized experience. There definitely some fine-tuning left to be done, which I’ve started logging. I also found some areas for improvement on Google’s part, that have also been mentioned elsewhere, like:

1. The ability to specify a bookmark image for a web app, kinda like when you add a bookmark to your home screen in Mobile Safari. Right now if you bookmark a web page on Google TV you get a screenshot of the page.
2. For some reason the Next/Previous media buttons weren’t registering, which I was hoping to use in “Slideshow Mode”

Visit the apps web page or play with the app

The initial implementation only took about 4 lines of code and was fairly simple. I just updated the top scroll position of the page based on the y tilt of the device. From there I just added things like reseting the initial tilt of the device when you load the page and allowing to to reset it manually with a button.

You can view the final example on your iOS device here. Keep in mind that you must have iOS 4.2 for this to work.

Then, magically, an associate walks up to you and knows you by name. I was totally confused, but then realized that the person I talked to initially had written down a description of me (“Green Coors shirt”) and that’s how I was found. It was all just really disorienting.

I’d love to have visibility into how they describe people. I’m sure it would make a very popular website.

The apps were fun to build and we used a number of Adobe technologies to pull them off. We’re hoping to keep pushing the multiscreen experience to include TV using Adobe AIR and an app for iOS. In the meantime, you can check out the images of the app in this post, our slide deck and our presentation on Adobe TV as soon as it’s available. We hope to follow up with a series of blog posts on how we built these apps.

When creating a theme it is important to consider that the Flex 4 SDK also allows for Flex 3 components to be used side-by-side with Flex 4 components. This means that skin artwork you create for Flex 4 components won’t get applied to Flex 3 components. However, there is a way to repurpose your pixel-perfect artwork for use with Flex 3 component skins. Be warned though, getting things to work properly will require some technical steps in MXML.

Part of the Flex 4 SDK includes a special skin class called SparkSkinForHalo. This class allows  you to repurpose your skin artwork and assign it to a Flex 3 component. While it does take an additional effort to account for the Flex 3 components, the additional skins will help insure consistency for both Flex 3 and Flex 4 components. Let’s see how it works.

1. Create a new folder and name it HaloSkins.
2. Create a new file called HaloButtonSkin.mxml and save it into the HaloSkins folder you just created.
3. Open the MXML file that contains your Button Skin artwork for your Spark components.
4. Copy the all the markup and paste it into the HaloButtonSkin.mxml file replacing any markup that might be there.
5. Locate the line that uses the s:Skin tag and in its place use local:SparkSkinForHalo. You also need to change the State tags from s:states to local:states and add a definition for the local namespace.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

<local:SparkSkinForHalo xmlns:s="library://ns.adobe.com/flex/spark" xmlns:fx="http://ns.adobe.com/mxml/2009" xmlns:d="http://ns.adobe.com/fxg/2008/dt" xmlns:ai="http://ns.adobe.com/ai/2009" xmlns:flm="http://ns.adobe.com/flame/2008" xmlns:local="mx.skins.spark.*">
 
<fx:Metadata>[HostComponent("spark.components.Button")]</fx:Metadata>
 
<s:states>
 
<local:State name="up"/>
 
<local:State name="over"/>
 
<local:State name="down"/>
 
<local:State name="disabled"/>
 
</s:states>

1. Delete the RichText, which is the label for the Button, from the skin. The reason you want to do this is that Halo components already have a label defined as part of the component.
2. That’s all you need to do for the skin. Now, you need to assign the skin to the Flex 3 Button.
3. Go into your CSS file and create a new style declaration for a Button with the MX prefix.

1
2
3
4
5
6
7
8

/* CSS file */
@namespace s "library://ns.adobe.com/flex/spark";
@namespace mx "library://ns.adobe.com/flex/halo";
 
mx|Button
{
skin: ClassReference('components.HaloSkins.HaloButtonSkin');
}

1. All that’s left is to test the skin. Add an mx:Button to your primary view and run your application. You should see that the Flex 3 Button looks the same as the Flex 4 Button. You may need to define the mx namespace.

Now that you know how to reuse your skin artwork you can take the same steps to make sure all your components for Spark and Halo look the same. For an extensive view at how to do this across all components you can refer to the sample skins provided as part of the latest builds of the Flex 4 SDK.

Note: You can make a custom theme using only CSS, but keep in mind that the CSS properties for Spark skins and Halo skins are quite different. Refer to the documentation for both SDKs to learn about what styles are supported or take a look at some of the sample CSS themes provided with recent builds of the Flex 4 SDK.

Think about your current television. What’s great about it? Well, a great thing about it is that it can provide an awesome viewing experience. You can be instantly immersed in that experience with very minimal distraction.

Now, what sucks about? For me, it’s finding content. Endless scrolling lists, crazy remote controls and complicated set-top boxes. Granted, I only look forward to a few shows a week, but still, when I’m looking to watch something and tune in I immediately get overwhelmed. I just want to view stuff that’s relevant as quickly as possible.

Some solutions I’ve seen try to solve this by allowing you to search. Which may be part of the solution, but I really don’t want to have a keyboard on my lap to go with any remote controls. I’d rather just get rid of all that.

So, what’s the solution? As I mentioned, some of the technology we may have heard about may already be prepping us for a solution, beginning with the apps on your phone. Think about it? The apps you choose to download already begin to create a profile of your interests. Imagine if there was a way for those apps to display their content on a TV as easy as going into landscape mode or taking a picture.

We browse a ton of content on our iPhones, iPads and iPods. Wouldn’t it be cool, for example, if I were in the ABC Player app and while I’m watching a show I could tap a “Play on AppleTV” button, which would immediately detect my AppleTV device and start playing that content right on the TV? Better yet, what if I’m playing Real Racing and want to switch my view to play on the TV? Simple, tap the “View on AppleTV” button and now my iDevice turns into a controller and my view is now on the TV!

How would this work? We’ve already seen something like this on the iPad when you connect it to an external display. When you do, a completely different viewing version of the app is shown on the external display, while you go into a different mode of the app on the iDevice. This same thing would be great for TV because the iDevice could turn into the most appropriate thing for the way it’s being used. The iPad becomes the game controller or the iPad becomes the remote.

There’s one thing missing though; the hardware/software that connects the iDevice to the TV. How about that UI-less device people are buzzing about that is supposedly priced for $99? That device could sync what apps you have (wirelessly I hope) and when you trigger a bit of content you want to engage with on the TV, that triggers the AppleTV hardware with the app and you’re instantly in game/viewing mode, whether it’s content from the device or streaming.

Throw in GameCenter, iAds, an awesome OS, the ability for publishers to dictate content, a ton of devices ready to go and you may have that go-to-market strategy Steve mentioned. With it, there’s an opportunity to bring a whole new level of engagement to the TV. Would you pay $99 to get that? I would.

Side note: I used a lot of screenshots from iPhone and iPad because it’s what I had access to, but a lot of this stuff applies to other mobile platforms.