Archive for August, 2007

Netflix a User Experience away from the PC

Aug 07
29

Today the Netflix user experience of movies is 80% movie and 20% PC. The movie experience is all fun. The PC experience is somewhat fun if you’re a technologist but rating movies and building queues isn’t most peoples idea of fun. What if you could continue to pull the user experience away from the computer and still provide the same value?

The idea is to use the evelope not only as a mechanism to return movies but also as a feedback device. At the very core you could allow users to rate movies by scratching or peeling off stars. This would make it easier for the user to give the system meta-data without having to pull open a computer and login. The idea could be extended for adding movies to your list of things to watch… “If you liked this movie you may also like… please check the box to add them.” (The longer your list the more likely you are to stay with Netflix)

A lot of companies assume that the best design has to be on the computer. This isn’t true; sometimes the best user experience can be with paper where your interface is as simple as a pencil or even your finger nail.

Posted in Ideas, Television, User Interface | 1 Comment »

Charlie can’t get on the T

Aug 07
28

In Boston we recently got a new way to pay for the metro (called the T around here). Previously you would either use cash or buy a token. The previous system was really simple. Buy a token for a set fare, if you don’t have a token you can pay in cash at above ground stations.

There were three visible problems with the old system:

  • The train cars didn’t accept bills easily
  • The token machines didn’t accept credit cards
  • Many above ground stations didn’t accept tokens forcing people to use quarters and slowing down the whole process.

The Charlie Card hoped to address some of these problems without creating new ones. Unfortunatly things didn’t work out that way.

The new system has created many new problems both in the physical design as well as the touchscreen interface.

  • Previously if you had a token you would put the token in and move on. The token is round and it doesn’t matter what way you drop it in. This has been replaced with a ticket. If you insert the ticket you have a 3 in 4 chance of inserting it the wrong way. Yes, it has an arrow but people still make this mistake.
  • If you’re a frequent T rider you can get an RFID pass that helps solve the above issue. Only problem is you can’t buy these cards at the T stops and you can’t refill them at many stops either. This means that you still have to use cash…
  • The new metro cars now accept dollar bills. Using an automated bill rejector. In the original design there was a 2-inch hole, you would crumple up your bill and shove it in the hole. The metro driver would visually verify your fair. It wasn’t pretty but it did work. The new system allows you to hold up the whole line as you try to straighten your bill to feed it into the machine.
  • You can still use coins but they managed to screw this up as well. Previously the coin tray was a small concave bowl, this allowed you to drop your coins and they would funnel down. The new design is a convex dome so you have to put each quarter in one at a time.
  • The design of the touch screen system that actually dispenses tickets has enough design flaws to fill a book (or a nice newspaper column) The placment of buttons, the order and flow of pages the use of color and text violates many established principals of design. Many of the stations now have a dedicated person to help people work through the poor UI. Compare this to the elegant design of the New York metro touch screen and it’s night and day.

There are a lot of people in the Boston community who are skilled in Usability and Human Factors. I had even sent an email to the MBTA volunteering to help them re-design the system and my offer fell on deaf ears. If anyone from the MBTA is listening my offer still stands.

Posted in Usability | No Comments »

Misconceptions with SSL security

Aug 07
27

SSL security is supposed to give a ‘secure’ connection to a website but there’s an inherent problem with the way that SSL is done. There are two parts to security.

  • A secure connection – when sending data between two computers a secure connection ensures that the data stream is secure from point A to point B. (Armoured car)
  • A secure identity – when communicating with a website a secure identity can tell you that the person you’re communicating with is who they say they are. (A registered identify and address)

A simple analogy would be an armoured car is your secure connection getting your data between places and the registered address ensures that the data is traveling between the right locations. That’s the theory…

An SSL certificate allows you to have a secure connection and at the same time ensures that your address is correct. This in theory isn’t a bad thing but the problem is that SSL does a good job of securing your connection but it does a much worse job of ensuring your identity. Anyone can purchase an SSL certificate for between $10-$400 a year. Secondly users don’t pay much attention to the identify and very little to the address. This means that the ID info isn’t that important, you really just want the armoured truck for the secure connection.

Imagine a large website with 100 servers. Each server is numbered and each connection has it’s own address. www1.example.com www2.example.com and so on. Each one of these seperate sites needs it’s own certificate. At up to $400 each per year the certificate over a couple years can end up costing more than the computer.

Unfortunately you are not allowed to use the armored car (secure connection) without a notarized address (signed certificate). If you want to move data securely between two computers your web-browser won’t let you do it. You could try to notarize the address yourself, this is called self-signed certificate but web-browsers don’t let you do that either.

This is bad because it forces many web developers to choose between spending between hundreds of dollars or using no security at all. The vast majority of sites don’t use any security. Only banks and shopping sites take this more seriously and even on these sites the certificates can cause problems. Try this… type https://yourbank.com  (notice I left out the typical www’s).  Chances are you’ll get an error message. Bankofamerica, CitizensBank, CitiBank, Etrade, Charles Schwab and countless others forget to buy a certificate for some parts of their website.  As far as SSL certificates are concerned each address is totally differen. www.bankofamerica.com is totally different from bankofamerica.com.   Yeah, this is dumb.

When you open a web-browser for the very first time and you enter your very first search into a search engine the browser shows you a warning about the fact that you are sending clear text across the internet. You get this message once and you forget about it but every day you may be sending thousands of personal bits of data out in the open across the internet.

From trivial gossip, passwords, secrets, bank cards and all sorts of other private information. If self signed certificates were allowed many of this information could be sent securely. It wouldn’t prevent every possible attack (you still want to use signed SSL in some cases) but for casual everyday use, email and basic browsing using self-signed SSL communication could prevent a lot of data and identity theft.

Posted in Browsers, Development | 1 Comment »

Beyond SQL – Making things IQL

Aug 07
22

The range in quality of web service API’s is huge. Some web services have great and well documented API’s while other websites and services have either no API or worse have a terrible API. What if we could level the playing field and create a basic way to allow databases to talk to one another to produce better quality more interconnected information.  I call the idea IQL or internet query language (pronounced equal.)
Simple scenario:
I have a contacts database. In this database I have columns such as “FirstName,LastName,City,State,Country.” I decide that I want to  enumerate countries so I use a country ID and link to another table called “Countries.” The table is simple and has things like ID, Country Name, Country Code, and perhaps a few other fields. I release my application and 1 year later that table is out of date because I don’t ever maintain the Country table.  And this isn’t just Countries, it’s States, zip codes, geo-political boundaries, the names of cities and towns, etc, etc, etc.  My database has become a data prison for stale data.

What if we could give our database some additional smarts and allow it to connect with other databases on the internet. The idea is to create an internet based query language similar in syntax to SQL to allow you to query and join tables across the internet with data that is local in your own database. The best way to explain the idea is to show 5 hypothetical queries that aren’t possible today but would be with an Internet Query Language.

  1. Select ID, Counties from “www.un.org/countries.xml”
    I’ve constructed a simply query that talks to a static files and allows me to use the data as if it’s local. The server I’m talking to can be a simple HTTP server or something smarter and more complex. The XML file is a basic example but it could be much smarter…
  2. Select Candidates.Name,Candidate.Party from “en.wikipedia.org/wiki/2008_Democratic_presidential_candidates/data”
    The data you querry can be part of a public system like the Wikipedia allowing people to extract knowledge from the masses.
  3. Select States.Name, States.Abbreviation from “www.senate.gov” CACHE 300 days
    Since talking to external databases can be slow we want to make sure that data is cached when possible. Here I’m suggesting that we retrieve a list of states but that we keep a cache of that list in our own local database for 300 days. We’re unlikely to add a state very often but if we do get our 51st state we won’t have to update every contact database in the US.
  4. Select amazon.com.Book.ISBN, amazon.Book.Link, Nytimes.com.Bestsellers.ISBN from “www.amazon.com”, “www.NyTimes.com” INNER JOIN ON amazon.com.Book.ISBN = Nytimes.com.Bestsellers.ISBN order by amazon.com.Book.SalesRank

    In one line I’m showing a new type of mashup. I’ve joined the Amazon database of books with the New York Times database of bestsellers.

  5. Select Videos from “YouTube.com” where Video.rating > 5 and Video.postedDate = ’10/20/2007′
    Select Photos from “Flickr.com” where Photo.stars > 5 and Photo.Uploaded = ’10/20/2007′

    This basically is shows that you can have a data API to query any website. Now that everyone is doing API’s and web services it becomes clear that some API’s can be great and easy to use while others are a total pain. IQL can level the playing field and allows you to query services in a similar way, all you need to know is the schema.

Potential issues:

- What happens if the schema changes?  In the same way that SQL can have views the recommendation when setting up a data server is to also use data views so that the schema can change but the view can stay the same. So if the schema changes it can impact your application. If you use a Cache you would fall back on the cache data allowing you to update for the schema change.

- What about security?  It would be up to the data provider to create a policy for what data to expose publicly and what data to keep private. It makes sense for many databases to stay private but it may make sense to make a lot of databases public.  The basic design as currently shown is read only. Updates, deletes and other operations would not be supported initially. Additional levels of security (username/password/API token) could be added later.

Performance issues… It’s possible to create queries that would return so much data it could harm a website. For example returning a list of every book on amazon or every item on ebay may not be a good idea.  Part of the administration of a IQL server would be to limit queries by time, memory and CPU resources. Some sites could require result limits to prevent performance issues.

Posted in Ideas | 1 Comment »

Great Photo Quality – by Default

Aug 07
20

Over at Raizlabs we’re working on a new photo sharing product called PicMe. There are a lot of photo sharing tools out there are we think ours is pretty different. Apart from the unique interface and the desktop based approach one principal that we have is: “Great quality photos, by default.”

Photos create memories and the beauty is in the details. Here’s a quick look at some of the key players and how they display your photos by default:

Note: This is the default image resolution when you open a single image, For many of these services it’s possible to get a larger resolution image but it’s not the default.
Because PicMe Photo Sharing is a desktop based application we can use a higher quality image (usually double what others use) and resize the image with anti-aliasing at the resolution of the monitor. This means if you have a really nice 20″ LCD monitor you see the details of the photo by default. This also means we can do some cool things with multi-mon and full screen mode and caching that can’t be done within a browser. Have you tried PicMe yet?

Posted in Raizlabs | No Comments »

JavaScript rubber band

Aug 07
12

This is a simple Javascript rubber band funciton that I wrote. Typically an animation function moves directly from point A to point B. This gives a very mechanical feel. I wrote a very simple rubber band funciton. This animates an object with velocity. The object can overshoot the destination and bounce back. The further you drag the farther it bounces.

Grab this and drag

Tested and seems to work in FF, IE and Safari.

Posted in Development, HTML/CSS, Misc. | 3 Comments »

RIML – Reduced Instruction Markup Language

Aug 07
9

Traditional HTML is a “complex instruction set” language. It’s got tons of tags, properties, and semantic definitions.

What if there was a reduced instruction set markup language. The idea would be to come up with primitives that could be used to layout a page and try to design the language with the minimal set to express complex designs.

My primitives:

  • Point
  • Line
  • Box
  • Polygon
  • Circle
  • Text
  • Image

Pretty simple so far. Each has a set of properties some specific to the element some global:

  • Position (top/left/right/bottom)
  • Height/Width
  • Color
  • Rotation
  • Semantic description (optional)
  • Data (Rich text data, Image data, font data)
  • Actions (Hover/Click/Drag/Etc defined in a scripting language)

Any element can be nested within another element or within a set of elements. Existing styles and elements can be referenced across a page. Note: I’m not specifying common controls. These would be pre-defined styles using the same core-elements and actions.

Using this type of simple language you could build the foundation of a new type of web rendering engine.

This simplifies the implementation of the browser. This means you can express more complex designs in a simpler and more straight forward way. The core ‘brains’ of the design would happen at design time in a design tool rather then at run-time. The relationships, positions and attributes are not interpreted, cascaded or defaulted. This means you have a tool that better represents designer intent.

Why is this in my head today? Once again I’m frustrated by the lack of browser support for key design oriented features. Did I mention that I don’t think CSS is so hot? I also read the proposal for new HTML 5 spec and it’s more of the same. I’m not impressed. Designers deserve better.

Posted in Browsers, Development, HTML/CSS, Ideas | 4 Comments »