Check out the Ensemble Biological Motion Demo

On the implementation side, using VBOs instead of packing the points into textures resulted in massively redundant data (some values need two copies for each frame of motion). VTF would have significantly simplified the implementation. Luckily, the Angle Project has it implemented, and the canary build of Chromium/Chrome (version 13) has integrated the changes; Firefox should have it eventually as well. I give it 3-6 months before public release versions have it as well.

• Getting a WebGL browser
• Firefox 4 and Safari partially work but do NOT have advanced vertex features
• Chrome’s WebGL support is similar, but the features can be enabled:
  • Close all Chrome windows
  • Windows: [UserFolder]\AppData\Local\Google\Chrome\Application\chrome.exe --use-gl=desktop
  • Mac: /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --use-gl=desktop
• Chrome’s and Firefox 4′s default vertex shader compiler has trouble with texture sampling in the vertex shader, so the demo skips that feature for those browsers. As Al mentioned in the comments, the plan to add the capability to the WebGL engine is in place.

After multiple people asked, I decided to give WebGL a try. I’m impressed but also annoyed.

Trying some features out
Check out my modified WebGL moon demo. Some credits are in the source.


Overall thoughts on WebGL
Pros:

• The graphics performance is an order of magnitude above any other web technology
• Again, it’s really fast!
• It stays fairly true to OpenGL (which is good if you’re familiar with OpenGL)

Cons:

• The graphics performance is noticeably slower than a desktop app. And forget about using your CPU for anything else.
• It says fairly true to OpenGL (is that antiquated, procedural, state-machine-based API the best that anyone can do?)
• No released (non-beta) browser can run it by default.
• It is OpenGL ES, rather than full OpenGL. Radom functions are just not implemented, but no documentation mentions what’s missing. In some cases whole features just don’t work (e.g. geometry shaders).
• The crippled GLSL doesn’t have most built-in shader variables like texture coordinates and gl_normal, so you need to make your own “varying” pseudonyms.
• HTML, javascript, and GLSL… ALL IN ONE FILE! Readability is lost.

Overall compatibility and tools (text completion and debugging those files) are going to be the primary determining factors in WebGL’s success. It’s early, so we’ll have to see what happens.

Suggestions:

• Categorize people (work, friends, etc.) and colorize and filter their posts
• Use more interactively responsive visuals to enhance ‘scents of information’
• Let me opt out of people’s individual networks (e.g. Google reader).
• Make privacy issues transparent (give a clear view of follower network)
• WTF is with modal popups for viewing follower list?
• Social networks are a big enough distraction at work, and Buzz(1) is attached to gMail! Needs a clear (temporary) off button!
• If someone follows me, I should be able to view their posts
• Let me mention people (@person)
• What’s novel about this? Give me a really compelling reason to use it other than "it’s next to gMail".

As for the "beta" tag, Google needs to stop it. Put up or shut up. User test software and then release it. Slapping a beta tag on everything just reminds me of Google’s history of poor support.

I would like a good social network aggregator, but Buzz isn’t quite there.

*Update: looks like someone (I believe an ex-Google employee) has set up a site to vote on Buzz improvements/fixes.

I do not share the generally positive view that others have given. It’s just a nice video with some horribly poor assumptions and the repetition of unoriginal ideas.

1) Multitouch does not make you into a multitasking god. At about 45 second in, they show four sliders moving independently of each other. This premise is so fundamentally flawed, that I’m astounded. The limitation of a single point of interaction doesn’t come from the mouse; it comes from our attention and cognitive limits. Multitouch may allow the computer to receive multiple sources of input, but that doesn’t mean that a single person can fully utilize it. Don’t believe me? Try this: Put both index fingers on the table. Move one up and down. Move the other left and right. Notice something? One of them very quickly will start moving diagonally or in a circle. Maybe you can successfully get through one cycle, but then your brain gives up. In multitouch gestures, though your fingers are at different locations, they all behave similarly. A stretch, a rotation, etc… all perform a formulaic motion about a focal point. Such gestures represent a single point of interaction using different styles. Did you notice ANY example in the practical portion where the video used “multiple points of interaction”? I sure didn’t.

2) The window layout proposal is unsubstantiated bullshit, and I have a publication to prove it (http://steveharoz.com/research/layout/layout.pdf). Our spatial memory is the best that we have, and it works very well in 2D. Layout doesn’t really matter; we can handle it. Furthermore, while swooping your hands around this completely unique piece of hardware (Wacom Bamboo Touch cough cough), how often do you think you’ll accidentally hit the left and right sides? Imagine if every other drag or mouse movement causes you to flip windows? You try dragging some files into an email, but the window switches and you accidentally drag them into Photoshop causing all of them to open. I already have that problem with my laptop trackpad where the right side causes a scroll. It’s annoying. What happens when you want a pdf and a website open while you’re working on a paper? I do that all the time. Here, you are just shit out of luck.

3) They didn’t actually DO anything in the “in practice” segment. It just shows that the windows can slide back and forth and that it has an alt-tab mode. I don’t get what I’m supposed to learn here.

4) Ever heard of a user study? Or at least some use case examples?!?

Overall, the video was well made, but the proposals were unsubstantiated and unoriginal. The hardware design – though unoriginal – is nice, but I’ll believe it when I see it. The exclusive factor that is slowing the adoption of multitouch is not software nor ideas about how to use it. Cheap enough hardware is just slow to come out. Apple and Microsoft have had multitouch in their OSs since Leopard and Vista. Good cheap hardware is finally making it to market, so we’ll see what happens…

A couple good ones from this year are making an interaction overly simple or overly customizable.

Some notes:

• You need a decent graphics card and updated drivers (Nvidia or ATI).
• It’s based on the OpenTK framework.
• It still relies on WinForms. Eventually I’ll try to use purely WPF, but the hybrid works for now.
• I definitely need to clean up the code and document it properly. Until that’s done, just email me if you have questions.
• The structure from motion demo looks best with anti aliasing overridden at the hardware level. For Nvidia cards, go to the Nvidia control panel –> 3D settings –> Use the advanced 3D settings –> Take me there-> Antialiasing – mode = override, Antialiasing – setting >= 2x. You can hit “Restore” or reselect ‘”Let the 3D application decide” to undo this change.

• Renaming a Window class.
  1. Rename the class in the .xaml.cs file. VS will nicely refactor all references including dependency properties (I hate that specific class names are needed for these).
  2. Rename the class in .xaml file. That’s right; VS doesn’t refactor XAML code. It’s not even nice enough to give you a compiler error, you have to run the program to find the unintelligable, unlocalized error. WTF?!?
  3. To maintain sanity, rename the the .xaml file with the new class name. VS is at least nice enough to rename the .xaml.cs file automatically.
  4. If you renamed the file of the startup window, you’ll get another meaningless runtime error. Yay! The fix is to open App.xaml and change the StartupUri.
  5. Compile and hope you didn’t make a single typo anywhere. Then recall fond memories of the winform days when refactoring took care of everything.
• Converting an application project into a library. It’s simple but unintuitive. Change the “Output type” in the project properties to “class library”. Now your application will completely break. The fix is to drop app.xaml and the .cs file from the class project. We shouldn’t have to do this!

I’ve heard a lot of frustration from numerous UX professionals about a lack of contribution to early design stages of a product or technology. I completely agree, as I’ve been asked to put lipstick on a few horribly repugnant pigs. Gaining power and influence at the top by having a UX architect is certainly part of the solution. But we also need to look at the other end of the spectrum… QA!

Looking at software engineering, the whole field really rests on an infrastructure of solid testing. They have patterns, theories about workflow, and many other aspects that are – at a distance – just like UX. However, software engineering has one critical tool that UX doesn’t: the unit test. It almost legitimizes the entire field. It’s not fancy or romantic, and the testing engineers are certainly not well respected or appreciated. However, this component is the backbone of software engineering. Pulling a feature may draw complaints from a few, but failing a test will really draw their attention.

How often do designers spec a UI and then not hear back until the product is released? How often are new features or limitations added without consenting with the UX team? We need to look at simple and easily repeated tests and designate stages in a product lifecycle for them.

• Do all controls afford interactivity? (highlight on MouseOver…)
• Are the primary personas’ goals achievable from the main screen?
• Does everything have a tooltip? Does it state the keyboard shortcut?
• What buttons have only text and no icon? Why?
• How does it look if I’m red-green color blind (5% of the population)?
• If I squint to blur the screen, can I make out the different regions?
• Yada yada yada…

Running these kinds of tests on the implementation rather that the design will allow UX designers to say, “IT FAILS”. That will force CEOs to start looking at UX with foresight rather than as lipstick.

I needed the ability to manipulate lots of geometry in WPF. Unfortunately, that’s just not feasible with the current framework, so I made this little demo to test out an OpenGL framework that I’ve been working on. It uses vertex shaders, pixel shaders, and framebuffers with some hacked together binding.

For those of you at MIX 09, this was the app that I was playing with.

Play Video

• Windows 7 Taskforce
• Apple OS X Taskforce
• Adobe UI Gribes