UI work

Last week I spent a huge amount of time getting the general interface of the relationship editor working: adding, removing, and changing relationships, along with the associated dialogs to do this.

Nothing can be submitted yet, but that's what I'm focusing on this week.

The UI in general took quite a bit longer than expected, because there were so many problems that occurred when an entity or relationship appeared more than once on the release. For example, some releases have duplicate recordings; even more have different recordings of the same work. When the user changes a relationship attached to one of these entities, it should change everywhere else it appears on the page.

These changes must also remain persistent if the user submits the form, but there are errors that they must correct. This is also something I'm working on this week. As it turns out, this isn't as difficult as I once thought: it's fairly trivial to embed the submitted CGI params in the page, and re-construct everything using JavaScript. I'm already halfway towards this goal.

The obvious missing features right now are batch relationship-adding/editing, batch work-creation, and release relationships.

The current progress is viewable at http://bitmap.mbsandbox.org/ - I try to keep this server running at all times, but keep in mind it's my development server, so it may not always work. The relationship editor is accesible from the the "Edit Relationships" tab on any release page.

More progress

At last week's meeting, we decided on a solution to MB's templating issues, but the design is yet to be finalized or implemented. At the moment my code still uses jQuery to clone hidden HTML fragments on the page, which is ugly and tedious.

My current challenge in implementing the relationship editor is the amount of information it needs access to on the page. To function properly, the JavaScript needs to know:

• What relationships the server has
• What relationships are pending (i.e. entered by the user), even if there's an error and the page refreshes
• A structure of link type data (including ids, allowed attributes, descriptions, link phrases, etc.).

These are partially solved by requesting this info from the database and embedding it into the template's JavaScript as JSON. If the new templating system were in place, it would be much nicer to be able request this data as it's needed (e.g. link type descriptions, attributes).

Some data we have to request as it's needed: for example, when a user searches for an entity, the rel editor needs to know all of its relationships. The XML web service is not sufficient for this, because it doesn't include database ids and other essential information. For this, last week I added an ?inc=rels argument to the /ws/js/entity web service: http://bitmap.mbsandbox.org/ws/js/entity/93889748-1092-3241-8b31-c648203415f3?inc=rels

With more of the backend in place, I've made a ton of progress. Although I missed the deadline for my first task ("Relate multiple recordings on a release to works"), I still feel that I'm ahead of schedule, because much of my code is portable to the other tasks, making them much easier to implement.

Small update

Some semi-exciting news is that I finally have a sandbox set up on mbsandbox.org, and I'll be pushing all of my changes so far to there within a few days, allowing people to test adding recording <-> work relationships. Once that's ready, I'll post a link here with instructions.

I'm at a bit of a roadblock with regards to templating. To display relationships on the page, both the client and server would ideally make use of the same templates. Otherwise, there's messy duplication that can lead to other issues. There's no existing solution for this in place on MB, so before I can write code that doesn't rely on such duplication, this issue will have to be discussed with the other MB server devs.

GSoC 2012 Intro

I'm working with MusicBrainz on another GSoC project this year! As you can see, this is the same blog as last year, so the older Picard posts are still visible.

I'll be coding a new tool for editors called the relationship editor (or rel editor for short). The rel editor will solve many inefficiencies WRT how editors currently relate recordings to works and add relationships to recordings and works on a release. It'll unify these actions under a single interface, so an editor can submit most or all liner note credits for a release in a single form. If this sounds awesome, it's because IT IS!

A good amount of work will center on making the interface intuitive enough to easily figure out, and simple enough so that working with it doesn't become a chore. I'm not a UI designer, so I'll be taking a lot of feedback into consideration. If you're curious, here's the mockup I created for my initial proposal. While the basic UI actions should remain the same, the final layout may have significant changes!

Because of this project's size, it was broken into smaller tasks. My first task (due on June 10) will allow "relat[ing] multiple recordings on a release to works (using the performance and medley relationships) under a single interface." If you're familiar with this browser script, then you're aware how much more efficient this is than navigating to every recording page and submitting each relationship separately.

That's all I have for now, so stay tuned for an update once my first task is nearing completion!