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!

Misc. Fixes

With all of my reviews open for most of the week (and nowhere to push my changes to without a 0.15 branch), there's no exciting new features to report on today. But I still fixed a good amount of issues people were having:

• Track times now sort numerically (previously it would sort 10:00 before 2:00). (code review)
• A bunch of small fixes to clustering (check for duplicate clusters, allow clustering albums with no alphanumeric characters). (code review)
• Updated Picard's release format list so that it matches the main server (meaning they should become translatable now). (code review)
• Track lookups are now queued (albums will load simultaneously with track lookups, and won't be stuck on [loading album-information]). (code review)
• Some compatibility fixes for the lastfm plugin. (commit)
• Added Ctrl+I as a shortcut for Edit->Details. (commit)

The standardized metadata diff passed code review and was merged into lp:picard over the weekend, too. The feature has been getting more feedback, so if I make any revisions I'll mention them in the next post.

This week I plan on starting collections support (which might overlap into the next week) and try to bring back preferred release country support (which depends on whether or not a server issue gets fixed).

Standardized Metadata

Now that MusicBrainz has "tracks" separate from "recordings," MB editors can capture small title variations across releases where they'd previously have to standardize them according to Consistent Original Data and other guidelines. Even artist credits now allow for variance from actual artist names per track and release. This flexibility is great for the database, but Picard users might be annoyed by the inconsistency it can bring into their collections.

This was my motivation for adding options to ignore all of this lower-level metadata and use the more-standardized recording titles, release group titles, and artist names to tag with.

The default option "as on cover" is meant literally, and will tag your files with metadata as it likely appears on a specific release: using track titles, release titles, and artist credits.

Implementing the logic for this was very simple. All of the standardized metadata we need is available from a single /ws/2 release request, so it was just a matter of choosing what to parse. The hard part was developing the actual GUI options (and in fact, what you see above is still tentative). I'd never been very familiar with Qt Designer, so it took me a few hours to figure out how to space and align things exactly. I introduced an odd graphical glitch along the way too, which has since been fixed. (Thanks to Philip Jägenstedt for reporting the issue.)

There's now the question of whether or not these options are intuitive to users (especially those not familiar with how MusicBrainz stores things now). Then again, the same could be said for plenty of other options already in Picard…

Anyway, the code review has been submitted, so we'll have to wait and see how the feature evolves from here. Once it's reviewed by other developers and accepted (possibly after a few revisions), I can merge everything into the main Picard branch for it to become part of the next version. (0.15 final?)

Introduction

Hi. \o I'm working on a GSoC project for MusicBrainz Picard this summer. You can follow the imaginably exciting development progress on this blog.

What will my coding entail? First, giving Picard basic support for the new MusicBrainz NGS web service. Would you believe that this is already done?! Download the recently-released Picard 0.15beta if you don't believe me.

This week I'll be keeping an eye on bugs people report for the beta, and try to address them. But now that the groundwork's implemented, I can also start working on some new features in Picard that take advantage of NGS:

• Ability to use "standardized" recording metadata (instead of track metadata) and artist metadata (instead of artist metadata as credited on a specific release). I'd like to start working on this during the week, so expect a blog post concerning it soon.
• Collections support. The ability to add or remove releases you're tagging from a collection on your MusicBrainz account.
• Investigate improvements to how we're displaying multi-disc releases. (This requires further discussion with other developers.)
• More? We'll see what else I have time for, if the community can think of any additional features that are wanted.

You might now be wondering about specific details of how these features are going to be implemented, or work in the interface. That will all come in future posts. For now, I hope this has shed some light on how I'll be spending my time.