The Iceberg Secret: Napkin Look & Feel!

Intended Audience:
If you've ever had to develop a GUI mock-up or prototype for someone in "management" before... this one's for you!



The Secret:
Let me introduce you to "The Iceberg Secret" of UI development. From Joel on Software:

You know how an iceberg is 90% underwater? Well, most software is like that too -- there's a pretty user interface that takes about 10% of the work, and then 90% of the programming work is under the covers. And if you take into account the fact that about half of your time is spent fixing bugs, the UI only takes 5% of the work. And if you limit yourself to the visual part of the UI, the pixels, what you would see in PowerPoint, now we're talking less than 1%.

That's not the secret. The secret is that People Who Aren't Programmers Do Not Understand This.

The Solution: (but only if you're a Java Swing developer)

The solution to your prototype woes is called the "Napkin" Look & Feel. It makes your GUI reflect the current state of its development: as if it was all written on a napkin during lunch and then magically scanned into a mock-up.



Some of the underwhelming (sarcasm) features:

• Crinkled paper background.
• Randomly rendered lines (aka hand-drawn with a pen) for outlines, borders, boxes, etc.
• Disabled == erased... even images get erased!
• Hand-written fonts.
• Menus and pop-ups... sticky notes!!!
  

(My favourite part is the "sticky notes" theming for menus and pop-up menus. It makes me feel warm and fuzzy inside.)


So, the next time the word "prototype" comes to mind... just think "Napkin"!


About the author: When the word "prototype" comes to Ethan's mind... he thinks "Napkin"!

Rave: Firebug extension for Firefox

I'm something of a web-development "purist". Many of my recent web-development sessions have boiled down to manually editing code--whether it be HTML, CSS, Javascript, PHP or SQL--using nano (like notepad for Linux). These sessions typically go something like:

code... code... code... open in web-browser... dang! ... code... refresh browser... code... code... aha! ... code [etc.]

When you're manually debugging PHP, I'd recommend the print_r function for starters. When you're manually debugging CSS... it's another story. (There's a reason it was named "Cascading".) In everything but the simplest HTML+CSS layout, there are usually conflicting styles and it never fails but that an unwanted style manifests itself. You can easily spend more time trying to fix CSS "bugs" than doing actual development because none of your inspector tools 'splain what's going on thoroughly.


The good news:
... Well, tracking down those pesky stylesheet issues has never been easier. I'd like you to meet my newest best friend¹: the Firebug extension for Firefox! It's an all-in-one browser plugin to make whatever you're doing on the web--from scripting to CSS hacking--that much easier.


In addition to awesome features like a content/connection profiler, it has the best CSS inspector/editor/debugger/whatever I've seen:

1. A "Click an element in the page to inspect" button that lets you take the problem right to the point of conflict. (No more endless DOM tree-navigation with DOM Inspector.)
2. A hierarchical view of active styles (by inline/external stylesheet) as well as listing inactive styles. When I figured out what I was looking at... well, my wife heard me shouting from the other room; it's that awesome.
   
3. Interactive style editing: to make sure it looks the right way before coding the styles, or to see how well your minor style "tweaks" look.
4. Layout guide: Click on a DOM element to see what the current padding, border, margin, and positioning are. Killer.
   

The real beauty of it is that the friend who recommended Firebug is even more keen on the Javascript features than the CSS inspector/editor--let the good times roll!


Images:

1. Firebug Layout Inspector:

2. Firebug Style Hierarchy:

Notes:
1. My previous new best friend was (and still is) jQuery.

VR Baby

I apologize if this article seems bit... light-hearted; I feel like taking a (small) break this weekend.

My daughter Isabella was born Nov. 10th, 2008. She's only 7 months old, but she's already got a head start on Virtual Reality...





Augmented Reality... labor time!

About a week before my wife was due, I placed her under house arrest—thinking that her taking things slowly would speed things up. It didn't help. When she was a week overdue, I tried to work from home "just in case". When she was a week and a half overdue, I found out about an Augmented Reality guest lecture by Steven Feiner being hosted at UF that evening...

Being a big fan of AR, I told my wife that I really wanted to go, but didn't want to leave her at home alone. She said she felt up to going with me to the seminar...

It was a great seminar. He talked about some of the uses of Augmented Reality and gave some examples of how it's currently being employed. Very cool—I'm glad I went. But as my wife and I were walking back to the car, she mentioned that she was having mild contractions. Needless to say, I started freaking out.

During the lecture, I had thought she was squirming because the wooden seats were uncomfortable (I thought so). But no, it was our precious little one trying to watch the guest lecture in person...


Virtual Reality

The next semester, I took the Virtual Experiences class at UF. The syllabus included 4 projects, each followed by a presentation to the class. Isabella came to see two of them.

The above picture shows Isabella wearing the V8 stereo 3D head-mounted display after I demoed a 3D space walk trainer/simulator.

I wonder what she'll get into now that I'm working at the Virtual Experiences Research Group at UF... ?




Other VR family members...

You can see my wife (Sherrie) in the video that Joon shot for our wheelchair simulator — she's the "manual wheelchair" driver. (We all thought it was ironic how a "virtual amputee" could have their legs crossed.)


About the author:
Ethan Blackwelder started working for the Virtual Experiences Research Group at UF in May 2009. He has NOT had a "Vasectomy Reversal"...

PS3 Motion Controller - Tech in review

To start off my Virtual Reality/Tracking series, this article provides a brief review and overview of the up-and-coming PS3 "Motion Controller".

Intended audience: Gamers and VR techies.


In the news:
At the E3 2009 Expo (June 2-4), Sony announced a new "Motion Controller" for Play Station 3.

What we know...

The PlayStation Motion Controller is a hybrid tracking system that combines the vision-tracking ability of the PlayStation Eye with internal motion sensors (either accelerometers or gyroscopes).

After seeing images of what appears to be the original Sony patent with hints of ultrasonic tracking for distance detection, I finally found this audio blog where SCE Chief Kaz Hirai explains that ultrasonic tracking was not implemented in the E3 prototype (starting around 1:45 into the clip).

The comments by Hirai are insightful: it appears that the motto for the motion controller is "less hardware; real-time accuracy". However his claim around 3:19 that "There's no time lag, there's nothing..." is obviously incorrect (just marketing).

I'm not sure what buttons/joysticks the final product will contain. (I'm hoping there is at least one button/trigger and one thumb-stick.)


A comparison of the Motion Controller to the the Nintendo Wii Remote:

Latency:
Although the PlayStation Eye acts as video input, vision recognition should be performed by the PS3 (perhaps using parallel processing?). The WiiMote does vision recognition itself using built-in hardware (it's quite a device). The PlayStation Eye is connected to the PS3 via USB, but the WiiMote communicates to the Wii via Bluetooth. Given these two facts, I'm sure the Motion Controller has at least the latency of the WiiMote, but probably better.

Frequency:
I can't find any hardware specs on the WiiMote's IR camera, but I think it's somewhere between 60 and 100 Hertz. The PS Eye can operate at either 60 or 120 Hertz. I'm willing to believe that the WiiMote's Bluetooth connection is not a limiting factor, so we'll generously compare 100Hz Wiimote to 120Hz Motion Controller.

Tracking:
In the video above, the tracking appears to be solid. I'm particularly interested in the augmented reality overlay around 2:30, involving the tennis raquet, baseball bat, etc. You may have noticed that there was minimal jitter (even at the tip of the bat) and that the orientation looked correct as the fella turned it in his hand. My hat is off to Sony!

Motion sensing:
The Motion Controller claims to offer near one-to-one motion control in all six directions. The Wiimote requires the Motion Plus attachment to get nearer to one-to-one motion sensing than the WiiMote alone. We shall see...

Price:
The WiiMote + Nunchuk costs about $60. The PS Eye costs about $40. Since the Motion Controller is "just" a wireless light bulb with buttons, it could (hopefully) cost as little as $15 or $20, but you may see it marked up a little higher. Certainly "affordable", as these things go.


Summary:
I think both Nintendo and Sony need a round of applause: Nintendo for pushing the envelope by introducing built-in, lost-cost tracking into the Wii, and Sony for what looks like a high-quality, affordable tracking and motion controller system.


About the author: Ethan Blackwelder has experience as a student, researcher, and developer in the fields of Virtual Reality and Tracking. He currently works at the Virtual Experiences Research Group at the University of Florida.

SCM in Review

In this article, I provide a brief overview of Source Code Management/Version Control Software and why every developer needs it.

Target audience: Developers who don't know about (or don't use) version-control. If you are a developer, you must use version control software! (Sorry for shouting; I'm emphatic about this.)

Overview:
Source Code Management (SCM)--aka Version Control Software (VCS) or Revision Control--is used to maintain a revision history for some set of code (or any other version-worthy stuff). Note: in this article, I will use the acronym VCS because of other uses of the acronym SCM.

Motivation: (or... So what's all the fuss about version-control?)
Whichever model you choose, version-controlling your software captures not just the current state of the code, but a revision history of the code. This is useful for several reasons:

1) It lets you rewind changes! Let me start with an example... The class was Artificial Intelligence Concepts and the term project was creating a game-with-AI-player in LISP. I didn't know LISP when I started, so let me assure you the original game implementation smelled pretty bad. So, in the middle of term-project "crunch time", I happened to get fed up with some of the old code and started "fixing it up". Lo and behold, the game breaks and I can't for the life of me figure out why. Luckily, I was using VCS. Using the revision history, I found a revision/version of the game that was working correctly. I then put all the broken code in an "experimental" branch and reverted back to the working revision. I then incrementally merged changes from the experimental branch to the "baseline" code. Without revision control, I would have been screwed; possibly having to start completely over at the last deliverable/project submission.

2) It stores "meta" information about current and previous states of the code. Some of you may be familiar with the practice of annotating small code-changes you have made with initials/date. You know, something like this:
foo++; // EIB 2009-06-13 - forgot to increment the foo.
... While this may have merit as a form of bookmarking (but why not just use your IDE's bookmark features? ... you're using an IDE, right?), it can easily get out of hand. Alternatively, how do you track code changes for someone who isn't inclined to leave these little blurbs? Again, with an annotated revision history, you get all the following automatically:

• You can see who did what when (who changed what and when they did it).
• You can review old/previous versions of the code.
• You can do a side-by-side comparison (aka diff or "diffing") of what so-and-so did on such-and-such a date. (This feature is especially useful for doing code reviews.)
• You can explicitly refer to particular revisions/versions of the code. For example: Release 1.6R3 of product FOO corresponds to revision 1234.

You can also leave messages when you do change things (because the change itself is rarely self-explanatory). For example, in the revision history/logs you may find something like:
EIB 2009-06-13: (foo-bar component)
I forgot to increment the foo after each razzamatazz; this fixes bug #1234
(Note that the code can be left spotless and undistracting, and the "commit" message as verbose as necessary.)


Where do I start?
There are two revision control paradigms (models): Client-Server and Distributed. The client-server model has been around since before the 1980's; the distributed model is a more recent idea with most of the distributed VCS's being developed in the early-to-mid 2000's... I won't recommend which model to use, since each paradigm has its own advantages/disadvantages and each implementation has its own quirks/strengths/awesomeness. That being said, I prefer Subversion: good features, good documentation, good clients, and--more importantly--free. (I don't think anyone should pay for VCS these days...)

Required Reading:
How 'bout I let you out of class early today?


Stay tuned for more posts about version-control software, including a review of three common software packages: CVS, Subversion, and Mercurial.

Hello, World!

My intention for this blog is to off-load some of the useful knowledge I've gained while doing all kinds of development.

My hope is that someone who's looking for help will find it (let's thank Google for that).