[mythtv] Proposed MythMusic Interface Improvements

[Eric A. Litman]

"Daniel C. Casimiro" dcasimiro at cox.net wrote:

> I am looking for some feedback on a number of improvements (IMHO) to the
> MythMusic interface.  Please take a look at the screen shots found here:
> http://members.cox.net/dcasimiro/index.html.

There are some interesting points to what you've put together here. It would
be helpful if you could spend a bit of time creating mockups of the song
display/selection UI, as - in practice - that's dramatically more important
than an album selection widget.

> My biggest problem with the current interface is that it takes too long
> for me to find music. To alleviate this problem, I would also like to
> add the capability to filter albums/songs by letter. Again, the
> autoplaylists would help in this area. I was thinking of adding a
> spinner-type widget to implement the letter filtering, but an
> autoplaylist interface may work better.

Any UI that moves away from hierarchical browsing and closer toward keyword
or metadata searching would likely represent a significant improvement over
the current mechanism for managing a large collection. While browsing is a
familiar paradigm that should be included in any revised UI, its current
form (both 0.14 and 0.15) diminishes in utility as the size and variety of a
music collection grow - particularly for a keyboard-driven interface. This
is a flaw in hierarchical information display in general, and not
specifically an issue with either implementation.

MythMusic really needs two modes of music selection: a browsing interface
and a robust search interface.

For straight browsing, the existing Program Finder interface is good
starting point. It could be enhanced by adding the ability to re-sort the
list (via the 'M' key) by Artist, Album, Genre, etc., or possibly adding
spinboxes to additionally filter by genre, rating, etc.

For a search interface (autoplaylist or otherwise), how about something akin
to a Google-style keyword search (e.g. keyword, +keyword, -keyword,
album:keyword, artist:keyword, genre:*keyword*, etc.) that displays results
in a selectable list on the same screen as the search field. As keywords are
added to or removed from the search (and the user runs/re-runs the search),
the results list would update with the new result set. The user could move
(via remote control arrows or keyboard tab key) between the search field and
selectable box to switch focus and scroll/select items in the list, and
perhaps even play directly from that screen. Pressing 'I' on any selected
song could pop up extended information about that track. Again, variations
on this theme could incorporate UI elements designed to minimize text input
and mask complexity, such as spinboxes to filter by genre, rating, etc.
Alternatively, the UI could be limited to search input box and results
display, with modifier/grouping selection available on a popup via the 'M'
key.

As an interesting enhancement to this, the results list could try to group
similar items, either automatically (e.g. hierarchical by artist or genre
depending upon search criteria) or user specified. An example:

    input>  "The Beatles" groupby:album

    ( ) Help
    ( ) Help/01-Help!.mp3
    ( ) Help/02-The night before.mp3
    ( ) Help/03 -You've got to hide your love away.mp3
    ( ) Help/04-I need you.mp3
    ( ) Help/05-Another girl.mp3
    ( ) Help/06-You're going to lose that girl.mp3
    ....
    ( ) Various Artists - Tribute to the Beatles Reggae Style
    ( ) Various Artists - Tribute to the Beatles Reggae Style /1.
Yesterday - Dandy.mp3
    ( ) Various Artists - Tribute to the Beatles Reggae Style /2. Hey Jude -
John Holt.mp3
    ( ) Various Artists - Tribute to the Beatles Reggae Style /3. Come
Together - The Israelites.mp3
    ( ) Various Artists - Tribute to the Beatles Reggae Style /4.
Something - Phyllis Dillon.mp3
    ( ) Various Artists - Tribute to the Beatles Reggae Style /5. Let it
Be - Nicky Thomas.mp3

In this example the "( )" represents a selection box and the "/" between
albums and songs represents a level of the result hierarchy. Genre or other
groupings could be displayed similarly.

Ideally, keyword searching would be flexible enough to match as broadly as
possible by default (across filename, directory and ID3 metadata) , and
modifiers should narrow the search. This would be particularly useful in a
mixed collection, where not all songs are tagged or stored in a consistent
directory structure. It also makes the song selection process accessible to
the non-technical user who will never take the time to learn to input any
query more complex than simple keywords, while remaining powerful for more
adept users.

Here is an example of something nominally similar that TiVo supports in
their UI:

http://www.pvrcompare.com/TivoTitleSearch.jpg
(from http://www.pvrcompare.com/dtimages.html)

Not right on the mark, but it gives an idea of how the elements of this
might come together. It has the clear benefit of supporting users with and
without a keyboard, and someone's already done a MythTV UI widget for that
style of text input.  For MythMusic's variation on this theme, once again
the existing Program Finder UI could be a model to follow, replacing the
meta info display currently shown at the top of the screen with a textbox,
spinboxes, etc. and incorporating the letter-by-letter widget shown in the
screenshot above into the lower half of the screen. (consistency is a
beautiful thing...)

For reference, here's the current Program Finder UI:
http://mythtv.sourceforge.net/mc/mpf3.png

> I found a cool website, named Slothdog's Amazing CD / Album Cover Finder
> <http://www.slothradio.com/covers> where you can download cover art. I
> was hoping to design an interface that automatically pulls down art from
> Slothdog.

Nice.

I'd be happy to contribute to this effort if someone wants to take the lead.

-Eric

Related P.S.:

While we're on the topic of autoplaylist creation and/or search input, I'll
throw in my unsolicited vote that "%" be avoided as a user-visible wildcard
character, despite it being the default SQL wildcard and requiring slightly
less effort to parse before sending to the DB. Outside of the realm of SQL
databases (and Vaxen), the majority of the electronic information seeking
world uses regular expression or pseudo-regex matching with the good ol'
asterisk/star/* character.