#musicbrainz

and consistency is a part of refinement.

that's the route of killing features because they don't fit in with some "design vision"

but like, the relationship editor vs. the old “relate to…recordings” thing.

instead, we should talk about consistency and power

Huge improvement in usability though it could still use some tweaks.

basically, "easy" rings of making apple products :P

ianmcorvidae: Is that a bad thing? :-p

if it means one-button-mice, yes

Not an apple fanboi, but damn if a lot of the stuff that they force people to think about for iOS doesn’t make it easier to use while still letting you do just as much

I've literally never had the experience of it letting you do just as much

CallerNo6: yeah, one-button mice is a little excessive. :-)

trying to do any moderately-complicated thing on a mac tends to require circumventing the supposedly-for-usability concessions

basically, the Mac Way seems to more often result in things that are less powerful, rather than more powerful, in my experience

because the focus is on making it "easy", which most developers see as opposed to something being powerful

if told "don't have confirmation dialogs", most people will remove functions that require confirmation, not trust their users :)

ianmcorvidae: I find it to be more “just fucking do the obviously-right things right rather than giving an option”

obviously-right is very difficult to discern

yeah, it’s not easy. :-p

and from my perspective nearly everyone chooses "wrong" :P

ianmcorvidae: this is the kind of thing that I think should be unnecessary: http://blowfish.be/eac/Setup/setup1.html

(EAC being a good example of a program with more options than necessary)

cdparanoia is perfect though. :D

pierreghz: Not hardly. ;-)

It works.

pierreghz: most of the time.

Where are the problems? :P

error correction, accuracy checking, see the things morituri and rubyripper do to hack around its problems

https://thomas.apestaart.org/morituri/trac/tick... as well

it's free software, someone could just fix it

Clint: “just” :-p

Clint: and “could be fixed” is not the same as “perfect” :-)

point

anyway, yes, you're right that uninhibited feature creep is also bad, which I guess is why I *didn't* include "flexibility" on my list of virtues

I think ease of use with the potential for power is the ideal, but it's hard to achieve.

+1

anyway my point here is that the relationship editor is not *easier* to use, for the most part -- it's just more powerful

in some respects it's actually harder to use, since the mental overhead of keeping track of batch operations isn't completely trivial

ianmcorvidae: I think it’s clearly easer to use too, just with the huge reduction in the number of times you have to bounce around between pages

but it's certainly a lot less tedious :)

ah, but that's not ease of use, that's power

ianmcorvidae: No, the fact that I don’t have to click “relate to” a dozen times and wait for pages to load twice for every single one, is ease of use. :-)

even leaving aside the nice *power* things like “batch create new works”

no, all the batch-relating is power features :P

it certainly did both.

but the main improvement is in ease of use.

ianmcorvidae: we had the batch-relating before with “relate to…recordings”

yes, but now we have batch-batch-relating

o_O

as in you can batch together several related batch relations

(i.e. a relationship editor session)

gotcha

yes

(for better or worse there. ;-) )

since it tends to tangle the edit comments a bit

anyway, my metric here is: is your mental model of the system less complicated with the relationship editor? (I doubt it, since you still have to have the same understanding of how rels and works and what-have-you work)

definitely.

you still need to understand the system to use it effectively.

the interface is easier to use because it's a more powerful tool, but that's not strictly "ease of use", I mean :)

the relationship editor doesn't really reduce the mental burden of editing, which I think is fantastic and what we should be going for

(other than reducing the burden by displaying things better, but that's different in my mind)

anyway, I think we agree other than on terms :P

(and about apple products, but that was a tangent anyway :P)

aye. :-D

anyway, I guess what I mean is that "ease of use" is very open to interpretation and is usually done wrong, so I prefer to be more specific :)

hawke_1: did you get the stats you wanted?

nikki: nah, I just skipped it in favor of listing some examples

nikki: I might file a bug at some point to request that AR attributes be listed on the stats page though

ianmcorvidae: I guess maybe I’m not catching a difference between “easy to understand” which I think is not so easy to achieve for us, since musicbrainz is a complex system on a complex topic — and “easy to use” which covers the actual tools and what you have to do with them to achieve a given change in the system’s state.

(the latter has a lot of relatively low-hanging fruit, I think)

my point isn't that pursuing "ease of use" is *wrong* per se, but that "ease of understanding" is usually the first victim of a quest to make something easier to use

or, well, that ease of understanding is the easiest route to ease of use

sure, because a lot of things want to hide those details.

Like we often talk about hiding the details of masters because most people don’t know/care about them.

and you're right that we can't really make our system much easier to understand -- or less complicated to understand, at least

like the relationship editor is easy to use for me because it has lots of functionality but it's hard to use for me because there's so much stuff on the page

the latter is kinda hard to fix. it's hard to edit relationships without showing them, but showing them makes a lot of releases scroll right off the bottom :/

(it's basically exactly what I hate about inline relationships on release pages XD)

but yeah, I'm not saying we shouldn't pursue ease of use, I'm saying we need to be more specific so we don't inadvertently become theaudiodb by removing our complexity in the short-term pursuit of ease of use

e.g. their search works a lot better than ours

yeah, but their data model is hilariously bad :P

or I should say “easy to use”

our actual search results are mostly OK.

but the whole “you must select what entity you’re looking for” thing is just silly. :-)

hawke_1: speaking of which, would you mix the results or search everything but display results separated by entity type?

nikki: I think mixing the results is the only viable thing…

heh

I'm not sure. Discogs has it nicely set up right now.

guess we won't be getting that any time soon then :(

Returns results of all kinds, but displays results separated by type.

nikki: Otherwise you’d have to somehow have subsections, or scroll past all the works to get to the recordings or whatever.

At least in their autocomplete.

yeah exactly! the latter is exactly why I hate the idea

Jump links?

it's stupid to show barely matching artist results first if there's an exact work match

that's just a workaround :P

nikki: +1

Leftmost: discogs search is fucking terrible

hawke_1, their autocomplete works relatively well, and certainly a lot better than ours.

Leftmost: Looks like they only have three entities too?

Searching for things outside of autocomplete sucks, yes.

to get the mixed search to work right, we'd have to create a new search index over "everything together"

which might be tricky to code well :)

anyway, a search over all entities was already implemented in the search, but nobody's done an interface for it. I started but gave up about 5 minutes later once I realised it wasn't possible to use the results to display mixed results

Leftmost: Sorry, but when I type “Beatles” and their autocomplete doesn’t have the beatles listed? That’s fucking terrible.

nikki: Yeah, I remember that being the case. :-(

hawke_1, I said "relatively". I didn't say it was a shining example.

the current method does separate searches over the individual indexes for each type

weird how most prepackaged search things *default* to searching like that

elasticsearch, for example, defaults to the '_all' pseudo-index, which searches all indexes

Why is that weird?

our separated-by-index system is the outlier at this point :P

Leftmost: I'm being sarcastic :P)

ianmcorvidae: well, musicbrainz isn't using any prepackaged search things ;)

Ahh.

kepstin-work: yes, of course we aren't -- I'm saying that we're behind the rest of the world because of it

theaudiodb searches all and splits results into columns.

hawke_1: columns by entity type (or their equivalent of entity type, whatever)?

ianmcorvidae: yeah.

which wouldn’t work well for us I think because we have too many entity types.

for columns to work, yeah

we could possibly get away with (release group, artist, recording, work, label)

but that’s five, and that’s unwieldy.

I mean, unless you're using a search term that only gets hits in a few of the columns

but you can't guarantee that :/

ianmcorvidae: with our search? Just about everything gets a hit

I dunno, most searches I do would only get hits in a few indexes

which is …kinda bad, but kinda good: we rarely have “no results found”, but we also get a lot of useless results.

heh

I think this may have more to do with the searches you're doing, I get no results all the damn time

At least our top results are usually the ones we want.

1 million recording results for “you belong to my heart” is just silly. :-)

kepstin-work: the problem is actually just the scoring. a label search for "morning musume" returns 100 for "morning records" even though only 50% of the search terms match only 50% of the entity name :( you can't combine them by score since the scores are some arbitrary thing that seems to resemble "how close is this to #1" rather than "how good is this match" :/

especially when the last page has a score of 0, with stuff like “the marching” by “hostages for smack”

nikki: yes; the only solution to that is to add a new index on the search server which combines all of the data.

I mean, I can’t even see the connection between the search query and the (last page of) the result.

well, using a different scoring system would also be a solution :P perhaps not as easy to implement but still

There is literally no word in common between the two.

heh

they has some letters in common :)

on the other hand, maybe it’s just our data being *that* stupid: http://musicbrainz.org/recording/af8edd1d-4a0e-...