another weblog

The big black monitor is one of these. There’s a lot of buzzwords in the product description, but it does live up to all its hype, as far as I can tell. For example, I threw it against the Lagom LCD monitor test pages and the thing pretty much passed everything. (and considering the cost, it’d better)

It works surprisingly well with Ubuntu, as does color management in general. There are some problems with applications that aren’t color-managed — this is one area where OS X has Ubuntu (and Windows) totally stomped — but that situation is improving, as is my knowledge of GNU/Linux-based color management in general. Currently, I have both monitors profiled and calibrated with Argyll, and my RAW decoder knows how to work with color profiles. I did final resizing and export in GIMP, though; and current versions of GIMP ignore color profiles, which is why the above image will look pretty whack, especially in the reds. I’m in the process of evaluating Linux-based image editors that know how to work with color; Krita and CinePaint look promising.

Also makes for a great software development environment. Nothing quite like having a four-up view on your source tree.

It’s cool that social networking things have made it easier to know everything that’s wrong in the world.

That said, I have read very little (actually, nothing) questioning the increasing reliance on a centralized system subject to the whim of a single entity. Twitter’s getting huge press over this election business, which I think will be very profitable for them (even moreso now they’re playing the hero role by delaying maintainance and graciously keeping the channel open), but wouldn’t it have been better if that single point of failure hadn’t existed? Especially with reports of Iranian authorities monitoring said single point?

You know, maybe something decentralized and federated — maybe something like this…

Now, I’m just some guy complaining about some abstract issue. I’m probably doing it too early. Some might say that I’m dragging out the soapbox, capitalizing on bad news. If you’re really pissed off at me for commenting on a tangential aspect of a popular event (that quite frankly likely has nothing to do with you), then you could say that I’m advertising (horrors!) one of my favorite tools. (You’d be wrong, because I don’t use Laconica or any service that uses it, but I’m certainly not going to censor you.)

Just think about it.

This YouTube video is a demonstration of part of the UI overhaul in Blender 2.5. The video is also available on Vimeo.

The video demonstrates the first fruits from the overhauled event system in Blender, but there’s two bits in the video that resonate with me because they’re facets of UI design that I try to achieve in my own applications. Those two things are tight feedback loops and simple interfaces to large, complex databases.

On feedback loops

Tight feedback loops are exemplified everywhere in the video demonstration, from the modifications to UI strings to changing material properties to the spin tool. In previous versions of Blender, you could not see the result of changing material properties without committing your changes in some way: that is, instead of being able to continuously manipulate widgets and see the result, you’d have to manipulate the widget, release a mouse button (or press Enter, etc), and only then could you see the result. It’s a small difference, but a huge win when it comes to interactivity, because it tightens the feedback loop substantially. Instead of

modify → commit → judge → modify → commit → judge …

it’s just

modify → judge → modify → judge → …

which means you do one-third fewer actions. The time you save, though, is a lot more impressive sounding than “one-third”, because there’s a lot of overhead associated with that commit action. (At the very least, you have to release or press a key and shift your attention away from the manipulator widget and towards the output.)

That search interface

Well, really, it’s more of a filtering tool. With filtering you start out with a large set of items and supply criteria to try to get to a smaller subset. Searching is the other way around.

Both processes have their place, but filtering is especially useful for the Blender object database. First off, the collection can be represented homogeneously: even though there’s multiple types of objects in the database (meshes and materials, to name two), they all have fields in common: a string ID, for instance. So the filter tool flattens out a complex hierarchical object database into a view which isn’t so good at representing structure, but is great for querying. Secondly, being able to pull up all the items in the database can serve as a reminder of just what you, the artist, put in there in the first place.

I don’t know if the search tool highlights objects in some way (say, if you hover over the ID of a mesh, it’s highlighted in the 3D view), but it does, that would increase of the utility of the search tool even more.

Why I care about all this

The sort of applications I write do the same sorts of things that Blender does. No, I don’t write 3D software, but I do write applications that allow people to modify and query large structured databases. In particular, the application I’m working on now models many aspects of laboratory workflow with directed acyclic graphs. Now, dags are very powerful abstractions, but you need more powerful UIs to facilitate interaction and querying. (The application I’m writing now has a Web interface, and the standard UI elements provided by HTML forms are, in many cases, very poorly suited to graph manipulations.)

So I find myself studying UI design principles, trying to figure out just what makes an interface empowering. These bits in Blender 2.5 correspond very closely to widgets and design principles that I’ve ended up implementing in my own software.

Because no Blender post is complete without this

There are of course the raging flamefests that always come up when “Blender” and “UI” crash together in the same sentence. I’m not going to comment on those because they always come down to the same tired few topics, and even though the occasional valid point is raised, it’s all irrelevant because people on both sides of the fence never bother to do things like read design documents. If they had done that then they’d understand that the point of all this work is foundation for more flexible UI customization, and that the video illustrates some cool and genuinely useful changes resulting from that work. Or, to wrap up: I just wanted to point out some genuine UI improvements in the Blender 2.5 series that I really identify with and like.

If you work with web applications written using the Ruby on Rails framework, you might find this useful. Everyone else can treat this post like the waste of time it is. (maybe not work-safe)

I decided that subclassing FormBuilder was my best solution to a problem for one of my work projects. Being the behavior-driven development masochist that I am, I wanted to develop my custom FormBuilder example-first. There is surprisingly little information about this floating around the interwebs, so I decided to throw out a first cut via code example. Simplifications welcome.

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

# build a ViewExampleGroup

describe CustomFormBuilder, :type => :view do

  before do

    # model name and model object

    object_name = ‘model’

    object = OpenStruct.new

    builder = CustomFormBuilder.new(object_name, object, template, {}, nil)



    # make the builder available to the view

    assigns[:builder] = builder

  end



  it ‘generates text fields’ do

    # run the builder in an ERb template…

    str = ‘<%= @builder.text_field(:foo) %>’

    render :inline => str



    # …and make sure you’re satisfied with the result

    template.should have_tag(‘input[name=?]’, ‘model[foo]’)

  end



  # …more examples…

end