Like many other Flex/Flash/AIR developers, I’ve seen Unity3D and I’ve said “Now, THAT’S what I’m talking about.” The stuff you can do in that program is simply fantastic, even if you’re trying to do something other than create a game.

Take for instance this post on visualizing a graph in Unity via a sqlite db and AIR.

I’d like to connect AIR to Unity in a more real-time way, and with AIR 2.0’s new socket server functionality. I’m guessing all you need is some Unity C# like this to add sockets to Unity, and then launch a Unity app in a browser from AIR, and then have that Unity app try to connect back to AIR via some standard socket.

I found this great video of a talk by UI designer Ryan Singer, by way of Jakub Linowski’s blog. Well worth the time as it compresses a bunch of great strategies into a nice concise presentation … and also made me think “hey, what happened to my Tufte books?”

All really helpful points. However, the stress on language decorating the UI needs some context. For example, I don’t know if the following UI would become more useful with inline, helpful text.

There’s probably an inverse relationship between frequency of use and the amount of helpful text that should be present. Or maybe frequency of use and complexity of task vs. amount of helpful text.

In my experience, those arriving to a UI design from a web application background tend more towards the extra verbage. Those arriving from the desktop world probably tend towards less, since the UI’s they’re building are not page-based and have a much less linear “flow.” The authors of About Face
captured this latter sentiment when they wrote that you shouldn’t focus all of your design efforts on the beginning user (nor on the power-user, for that matter) but rather aim for that somewhat frequent user in the middle.

Doing a lot of work in Flex and AIR means working with UI tools and frameworks that encourage less linear paths. This finds me often dropping a lot of verbage to clean up the interface for the frequent user.

I’m trying to get my AIR application to communicate with Basecamp. Should be easy. The guys at 37Signals have their signature REST simplicity going on and the API is just sitting there waiting for basic POST and GET requests via AIR’s HTTPService.

Ok, so I want to get my projects from the Basecamp API. Lessee here…reading through the Basecamp API (and translating to ActionScript) I just need to send an HTTP “GET” to my account’s URL, making sure to add on a “/projects” to the URL…something like https://myAccountName.basecamphq.com/projects

And, I also need to make sure that the headers include stuff like contentType=”application/xml” and I set the “Accept” property on the headers object to “application/xml” too. No prob.

And…AHA!….I need to take a little time to get the authentication header correct, as described by Alain Hufkins in this blog post.

Finally, as I mentioned before, if you want a simple list of your items (in this case projects), the convention in REST is to issue a GET request. So we’ll add this to our HTTPService’s settings as well.

Now, with just a little pompousness (soon to evaporate) we’ve got this thing down in just a few minutes. Here’s the code in my BasecampDelegate class, kind of squished together in one method so you can see it. I’m using the SWIZ framework, so the HTTPService is injected into the class’s “service” property, but you could just create the service within the method and everything would go. I also have a basecampModel class that contains the URL, username and password.

Ok! (Rubbing hands gleefully). Click debug/compile and …. wait…. Flex is tracing out that the request is being sent via “POST.” But I explicitly set it to “GET.” Try re-arranging how the parameters are set. Debug/compile … same thing. Arrrrrr!!! Ok, make sure the original tag is set to “GET”. Debug/compile … same thing.

“What the…”

It turns out that the HTTPService class changes stuff around on you when you’re not looking : if you set your contentType to “application/xml”, it doesn’t matter how many times you set it to “GET,” it’s going to send off a “POST” at runtime. Big thanks to Verveguy for pointing this out.

So, the way around this is to set your content type to x-www-form-urlencoded even though the Basecamp API docs tell you you need to send application/xml. This will work when you’re doing a GET.

I hope this saves you some time!

The program I’m working on for Lawrence Berkeley Labs — COMFEN v3 — just a took a nice step up thanks to a pair of designers at LBNL: Maria Konstantoglou and Anthony Ma. They’ve created a friggin’ sweet building graphic with some fancy swooshes from the future, which now appears on the right column of the startup page. The startup page looked good before but now it looks top notch.

So the UI just went up a level. Thanks guys. And, as always, thanks to famfamfam for a few of their icons.

I’ve been thinking about patterns for green building, and wondering why there aren’t more sites that collect and index these kinds of patterns as examples for interested architects and engineers.

Today I came across a site that does something like this:

http://architypes.net/pattern/design-process

However, unlike the OpenPV site I blogged about earlier, this one doesn’t provide any actionable data. It would be pretty cool if each pattern also offered things like: models built in SketchUp, energy analysis in graphic or raw format via EnergyPlus runs with OpenStudio (a SketchUp plugin), sensor data from a building that tried to use this pattern, etc.

Coming from the programming world, when I hear “patterns” I immediately look for data and tools and not just narrative and pictures. A coder that stumbles across some patterns descriptions (like at this site for ActionScript 3.0 patterns) usually thinks “Ok…now where are some examples I can download and try!” Narrative isn’t enough.

I wonder if architects and engineers feel the same way about resources such as these. They’re great, but they need to provide more actionable raw data for today’s design tools.