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.

[vimeo]http://vimeo.com/6702766[/vimeo]

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.

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.


public function getProjects():AsyncToken
{
Logger.debug(" what could be easier? ...")
service.url = basecampModel.basecampURL + "/projects"
service.method = "GET"
var username:String = basecampModel.basecampLogin
var password:String = basecampModel.basecampPassword
var enc:Base64Encoder = new Base64Encoder();
enc.encode(username + ":" + password);
service.headers["Authorization"] = "Basic " + enc.toString();
service.contentType="application/xml"
service.headers["Accept"] = "application/xml"
service.resultFormat = "e4x"
return service.send()
}

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.


service.contentType="application/x-www-form-urlencoded"


I hope this saves you some time!

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

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.

http://www.mail-archive.com/flexcoders@yahoogroups.com/msg127375.html

http://blog.esofthead.com/loading-modules-in-air-application-2/

I was browsing the site today when I came across their OpenPV Visualization flex app, an interesting way of browsing solar power installations. It collects the data the OpenPV project has compiled and lays it out in a google-map-plus-flex-dashboard mashup.

The app uses Flex Charting to good effect…I was never really big on the animated transitions offered by the graphs, but this application shows that they can be used to add visual interest without taking away from the basic task of reading some numbers to figure out what’s going on. Clicking from one zip code to another gives just enough animation to show you’ve changed data sets.

It’s great to see a these kinds of well-defined, well-designed repositories of open information in the alternative energy industry. I wonder if anybody is doing something similar for Green Buildings and the data they produce?

I often say that it’s a shame that the green building architecture and engineering industries don’t benefit from the open source mindset that’s improved the lives of so many computer programmers. Is it crazy to think that the kind of success and impact that Ruby on Rails has had could have an analog in the green building world? What would a 37Signals building look like — both in construction and in the final product?

Perhaps projects like OpenPV are the initial stalls in the newly forming bazaar around the architecture cathedral.

Problem is, there’s no language/tool combination on the server that will make you feel the same cohesiveness when developing in AS3.0/Flex on the client. Ruby on Rails + RubyAMF is nice, but not seamless. LCDS is powerful but expensive….ok there’s BlazeDS but now we’re still talking Java and stuff like Spring and Hibernate. ColdFusion 9 seems powerful but now we’re talking programming in tags, right?

I’m trying to sort out all the different benefits, drawbacks, dependencies and requirements of these different solutions (and then somebody comes along and goes, “yeah, but you know Scala and Lift are where it’s going to be at” to which I responded “uhhhh…must learn more.”)

Anyways, this post really is just a note to myself to remember that  Greg Wilson posted a bunch of links he amassed after doing a CF9 brain saturation.

And, following that, a helpful post by Holly Schinsky on data services and endpoints explained.