Presets (was Re: Dev chat 2009-04-06 irc log)

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Presets (was Re: Dev chat 2009-04-06 irc log)

Brian Schweitzer
There was quite a bit of various bits of discussion about the above,
clutter, when a feature has community support, usability, etc. ruaok
emphasised that community support and discussion is the key and asked
brianfreud to post on mb-devel about his presets proposal.


As promised, here's the quick version of the presets concept.

I find when I edit, I spend the vast majority of my time working on the same small set of release attribute groupings.  I also noticed this same thing for most other users, a year or so ago, when I was spending time trying to cover all English add/edit release edits.

What I mean is, when I've been editing lately, 99% of releases I'm working on tend to be one of:

Soundtrack Official English Latin
Soundtrack Bootleg English Latin
Soundtrack Official Japanese Japanese
Live Bootleg English Latin

When this was discussed in IRC, it was mentioned that it's easy to just tab through and set these from the keyboard; ie, for the first above: tab, s, s, tab, o, tab, e, e, e, e, e, tab, l.

While this is true, that's also
1) a lot of typing,
2) assumes you're a poweruser enough already to know the lists well enough to know what letters to hit to get the right options,
3) Really redundant, in my opinion, when I'm using the same sets of 4 selections from those dropdowns over and over.

So my idea had been for users to be able, in some way, to define "presets"; to predefine 1 to 4 sets of selections in those dropdowns, then to have those presets appear as buttons in the unused area on the right of the release attributes area of the add/edit all form.  Click one button, those predefined attributes get picked in the dropdowns.

I'm not locked in to any particular UI.  Here was my attempt at a basic effort on this:
In User Preferences: http://s2.photobucket.com/albums/y48/brianfreud/?action=view&current=prefspresets.png
In the form itself: http://s2.photobucket.com/albums/y48/brianfreud/?action=view&current=presets.png

If there were no presets defined, as I had the UI set, instead of buttons, it would show text reading along the lines of "You have no presets defined.  These can be set in User Preferences."  I could have also made it just something that didn't even show up until turned on in User Preferences.  (But there seems to be a general dislike for adding any new preferences (or even keeping those we have)).

There seemed to be three general objections:
1) This adds clutter to the form.
2) Noone other than myself would ever use this.
3) There is no trac ticket in requesting this, so there's no user demand for it.  (There is now, as I added one.)

So, the question is, is this something anyone would find useful, regardless of UI?  If you would find it useful, what UI, if not this one?  Or, is there some other, better way(s) to do the same thing?

The only alternate idea I've heard was for the add release form to recall the last attr set you used, and pre-set that.  I don't think that's a great option; it doesn't do anything on edit release, and it assumes that editors only ever work on one set of attrs - if it presets "Live Bootleg English Latin", and I'm working on "Soundtrack Official English Latin", it's not saving me any effort - and if the editor isn't paying attention, it allows the chance for incorrect data to be passed by the user as the settings for these dropdowns.

Brian

_______________________________________________
MusicBrainz-devel mailing list
[hidden email]
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-devel
Reply | Threaded
Open this post in threaded view
|

Re: Presets (was Re: Dev chat 2009-04-06 irc log)

Aaron Cooper-2
I know you probably don't want to hear this, Brian, but IMO "click, a
(album), tab, o (official), tab, e (english), tab, tab, L (latin)" is
a very quick way to set these parameters.  I think there's way too
much stuff on the screen already.  I'm contemplating learning how to
write GreaseMonkey scripts so I can remove some of the material so
that I don't have to scroll 3 pages while editing a release.  I
realize this wouldn't add any more vertical page length, but I don't
think it'd get very much use.

-cooperaa


On Mon, Apr 6, 2009 at 6:13 PM, Brian Schweitzer
<[hidden email]> wrote:

>> There was quite a bit of various bits of discussion about the above,
>> clutter, when a feature has community support, usability, etc. ruaok
>> emphasised that community support and discussion is the key and asked
>> brianfreud to post on mb-devel about his presets proposal.
>
>
> As promised, here's the quick version of the presets concept.
>
> I find when I edit, I spend the vast majority of my time working on the same
> small set of release attribute groupings.  I also noticed this same thing
> for most other users, a year or so ago, when I was spending time trying to
> cover all English add/edit release edits.
>
> What I mean is, when I've been editing lately, 99% of releases I'm working
> on tend to be one of:
>
> Soundtrack Official English Latin
> Soundtrack Bootleg English Latin
> Soundtrack Official Japanese Japanese
> Live Bootleg English Latin
>
> When this was discussed in IRC, it was mentioned that it's easy to just tab
> through and set these from the keyboard; ie, for the first above: tab, s, s,
> tab, o, tab, e, e, e, e, e, tab, l.
>
> While this is true, that's also
> 1) a lot of typing,
> 2) assumes you're a poweruser enough already to know the lists well enough
> to know what letters to hit to get the right options,
> 3) Really redundant, in my opinion, when I'm using the same sets of 4
> selections from those dropdowns over and over.
>
> So my idea had been for users to be able, in some way, to define "presets";
> to predefine 1 to 4 sets of selections in those dropdowns, then to have
> those presets appear as buttons in the unused area on the right of the
> release attributes area of the add/edit all form.  Click one button, those
> predefined attributes get picked in the dropdowns.
>
> I'm not locked in to any particular UI.  Here was my attempt at a basic
> effort on this:
> In User Preferences:
> http://s2.photobucket.com/albums/y48/brianfreud/?action=view&current=prefspresets.png
> In the form itself:
> http://s2.photobucket.com/albums/y48/brianfreud/?action=view&current=presets.png
>
> If there were no presets defined, as I had the UI set, instead of buttons,
> it would show text reading along the lines of "You have no presets defined.
> These can be set in User Preferences."  I could have also made it just
> something that didn't even show up until turned on in User Preferences.
> (But there seems to be a general dislike for adding any new preferences (or
> even keeping those we have)).
>
> There seemed to be three general objections:
> 1) This adds clutter to the form.
> 2) Noone other than myself would ever use this.
> 3) There is no trac ticket in requesting this, so there's no user demand for
> it.  (There is now, as I added one.)
>
> So, the question is, is this something anyone would find useful, regardless
> of UI?  If you would find it useful, what UI, if not this one?  Or, is there
> some other, better way(s) to do the same thing?
>
> The only alternate idea I've heard was for the add release form to recall
> the last attr set you used, and pre-set that.  I don't think that's a great
> option; it doesn't do anything on edit release, and it assumes that editors
> only ever work on one set of attrs - if it presets "Live Bootleg English
> Latin", and I'm working on "Soundtrack Official English Latin", it's not
> saving me any effort - and if the editor isn't paying attention, it allows
> the chance for incorrect data to be passed by the user as the settings for
> these dropdowns.
>
> Brian
>
> _______________________________________________
> MusicBrainz-devel mailing list
> [hidden email]
> http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-devel
>

_______________________________________________
MusicBrainz-devel mailing list
[hidden email]
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-devel
Reply | Threaded
Open this post in threaded view
|

Re: Presets (was Re: Dev chat 2009-04-06 irc log)

Nikolai Prokoschenko
Administrator
In reply to this post by Brian Schweitzer
Hi Brian,

> As promised, here's the quick version of the presets concept.

I'm getting the impression you are solving the wrong problem or rather not
solving it at all. The problem you outlined is a general "too many clicks to
enter a release". Even I feel your pain, although I'm a casual editor,
entering maybe several releases a month. I would probably enter more if the
editing system allowed me to do that fast without asking me stupid questions
all the time.

Your proposed solution is creating presets for release attributes. I see
many problems with that approach:

1. Even more buttons
2. Even more preferences
3. Even more confusion of users ("Which presets? Why would I want them? I
can enter more than one CD?")
4. It's definitely a power-tool in its current form and we actually need
more newbies to trigger the "given enough eyeballs..." effect.
5. It doesn't scale at all -- four presets? Is it enough for you? Don't
forget Murphy's Law: if this feature is deployed, you'd one day notice that
you need some other preset for the next week instead of the four you already
have ;)

You are solving a problem by loading it off onto users' shoulders -- now
they'd have to configure what they want. I can understand where this comes
from, but that's a "Greasemonkey mentality" in my opinion -- tackling the
interface a little bit just to make it a little bit easier. Developers
should be able to solve a problem fully while making it easier for the
users.

"Sane defaults, less preferences, more integration" is what we are aiming
for now and it's been a good aim for software development in general. Let's
see how this applies to release's attributes. Just my position below.

We *do* have an "I don't know option" so release attributes are per
definition optional. So let's make them completely optional and easy to
change *after* or *instead of* editing or adding a release. Don't forget,
we've got a release type re-work coming up which will complicate that one
form for adding releases even more. Why? Let's make edits more atomic, it
will be easier for voters to vote on them: "This release is fine, but it's
actually Russian/Latin instead of Russian/Cyrillic" -- what do you do? Write
an edit comment? OK, fine. But, if you already know what has to be changed,
change it! Then an inclined voter can just glimpse over it: "Oh yeah, it
looks Cyrillic to me, fine with that". You can't do that with current code
base because it's all in one edit.

Another use case are the newbies. We currently force them to make a decision
which they actually can't make: if you hold a newly bought CD and you just
want to enter it into the database, but you don't have a slightest idea if
you've got a bootleg or something. You assume it's legal, but how can you
really KNOW? No way, except for looking on the net for official
discographies, which might not be authoritative themselves. Either way,
editing a track list and adding release dates and attributes are different
actions, requiring a lot of research. Entering a release as early as it gets
might trigger positive collaboration when people watching that particular
artist start extending information. We started tackling that problem by
introducing CD stubs, but that's not enough yet.

Anyway, I'm slipping off to general edit system bashing, but considering
presets: if you want some relief from release attributes, take them out of
"Add release" and "Edit all" and give them their own UI, probably with some
magic for batch editing. Don't force additional configuration and overloaded
GUI on the users.

Nikolai.



_______________________________________________
MusicBrainz-devel mailing list
[hidden email]
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-devel
Reply | Threaded
Open this post in threaded view
|

Re: Presets (was Re: Dev chat 2009-04-06 irc log)

Brian Schweitzer
We *do* have an "I don't know option" so release attributes are per
definition optional. So let's make them completely optional and easy to
change *after* or *instead of* editing or adding a release. Don't forget,

I don't want to turn this into a style debate, but I would object to the above.  I am interpreting you as saying those are optional as in "well, set them if you feel like it", when I think the intent of those options is much more on the "if you really don't know" end of the scale, rather than the "well, if you feel like it" end.  Any change to the form that would actively encourage more people to leave empty easily set data here seems counter productive to me.

Brian

_______________________________________________
MusicBrainz-devel mailing list
[hidden email]
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-devel
Reply | Threaded
Open this post in threaded view
|

Re: Presets (was Re: Dev chat 2009-04-06 irc log)

Brian Schweitzer
In reply to this post by Nikolai Prokoschenko
Anyway, I'm slipping off to general edit system bashing, but considering
presets: if you want some relief from release attributes, take them out of
"Add release" and "Edit all" and give them their own UI, probably with some
magic for batch editing. Don't force additional configuration and overloaded
GUI on the users.

Sorry for the double response, but addressing this separate issue separately.  What I don't quite understand in this comment is the same as what I didn't understand in the similar comments made in IRC about the edit all form.  It is "Edit *all*" - the entire point of the form is that you be able to edit everything about a release from a single form.  This logic held until ARs were introduced, as they never were added in to the edit all form.  But apart from ARs, that "able to edit everything about a release" logic still holds true.  So my question is, why should the "edit all" form be reduced down, such that an editor needs to open separate editing forms to edit different aspects of a release?  Why should "edit all" become, well, "edit all (except for type a things, type b things, type c things, etc.)"?

Call it a power user issue, if you want, but I think this is more an argument for why the different types of specific edits (Edit title, edit track, etc) - tickets http://bugs.musicbrainz.org/ticket/4947 , http://bugs.musicbrainz.org/ticket/4932 , http://bugs.musicbrainz.org/ticket/4930 , http://bugs.musicbrainz.org/ticket/4929 , et al, need to remain, rather than a reason why "edit all" should be dumbed down or have functionality separate out (in the name of simplifying the UI and making for less crowded forms).  Whether it be full-out removing "edit all", or merely "simplifying" the functionality right out of it, either one I think would significantly and negatively impact the work flow of power users. 

A word on power users: we do need the power of the eyes and efforts of the masses, but the small power user community still does a significantly disproportionate amount of the corrective (not additive) editing on the site.  Changes to functionality, like this concept, in a way which would significantly and negatively impact power users, should be very carefully weighed, else we end up making it easier for newbies to add new data, but more tedious and tiresome (and thus less likely, and in less significantly effective amounts) for power users to work to fix that data, resulting in possibly more data coming in, but definitely less overall data quality.

Brian

_______________________________________________
MusicBrainz-devel mailing list
[hidden email]
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-devel