Feedback on the new 'Add work' mechanism

[MandyShaw]

Hi, this is excellent and saves loads of time, thank you.

A few things I've been intending to suggest for ages:
a) Could we have a 'net' option on the 'Sheet music format' field please? I am forever forgetting to make this change afterwards.
b) Could the form prompt for the lyricist?
c) Could the form prompt for lnktxt with a drop-down list of the relevant pages that exist?
d) Could the form prompt for lyrics text and translation(s)?
e) Would it be possible to add some more memory-joggers to the wiki text examples at the bottom of the editor screen? Here are the ones I always have to keep handy because I can't remember them:

{{Cat|SSAAT}}
{{MultiVoicing|5|n=2|1st=SSAAT|2nd=AATTB}}<br>

{{Top}}
{{Text|Latin}}
<poem>
</poem>
{{Middle}}
{{Translation|English}}
<poem>
</poem>
{{Bottom}}

{{LnkTxt|Quem vidistis}}
{{LinkText|2|Magnificat|Nunc dimittis}}
{{LinkText|Psalm 123|, vv. 1-3}}

Thanks
Mandy

[choralia]

Thank you for your feedback (and for your numerous contributions, which make the 2,000 goal closer and closer!).

The purpose of the new "automatic add work" mechanism is to enable new users submitting their works, especially for newcomers who are not familiar (at least initially) with wiki editing to copy-and-paste the fragments of wiki code required. The mechanism is not intended to provide any additional functions with respect to the "manual add work" process used since the beginning of ChoralWiki. So, I think that we should consider your valuable feedback from a more general perspective, i.e., not limited to the new mechanism.

a) Could we have a 'net' option on the 'Sheet music format' field please? I am forever forgetting to make this change afterwards.

Most externally hosted files have been historically tagged as "net", however I'm not sure that this makes sense as far as the file format is concerned. A pdf file is a pdf file regardless it is stored locally or not. If we really have to identify externally stored files with respect to locally stored ones, I would suggest to use icons that also include the format information, such as the "Extpdf". I don't know what other administrators and contributors would think about this. Other opinions are welcome!

b) Could the form prompt for the lyricist?
c) Could the form prompt for lnktxt with a drop-down list of the relevant pages that exist?
d) Could the form prompt for lyrics text and translation(s)?
e) Would it be possible to add some more memory-joggers to the wiki text examples at the bottom of the editor screen?

To encourage new contributors submitting their works, I think that we should keep the form as simple as possible. While adding a lyricist field would not significantly increase the complexity (we should do it for both the "manual" and the "automatic" processes, though), I think that showing options for lnktxt, text, and translation(s) might disorient newcomers. I would rather think about simplified ways to add similar things to existing pages, such as top tabs like "Add lyrics", "Add a new translation", etc. . Semantic MediaWiki might be a more general and flexible solution, however the migration of the current non-semantic wiki to a semantic wiki might be too a large task for our limited resources.

Max

[MandyShaw]

Re a), I have always endeavoured to follow what I thought was the de facto standard. I rather agree with you that PDF (or 'extpdf') would actually be more helpful from a CPDL consumer perspective.
The general purpose 'globe' feels to me to introduce a bit of a perception of externally hosted scores being less central to CPDL than internally hosted ones, which I am sure is not the intention.
In our case, the scores can be played back as well as downloaded in PDF format from our site, so would you say that we should specify MP3 as well as PDF, or does that tag demand the ability to download the MP3 (which we do not offer)?
It would be really useful if we could have a published consensus on these matters.

[choralia]

Currently, "ext" icon templates exist for pdf, midi, mp3, and Lylipond files. So, I would propose to use them in lieu of the generic "net" icon wherever applicable. The "add work" scripts may automatically select the appropriate icon when the corresponding conditions are detected. For file types where no "ext" icon exist, the normal icon should be used regardless the file is internally or externally hosted.

does that tag demand the ability to download the MP3 (which we do not offer)?

I think that the availability of an audio rendering of the score is sufficient to display the mp3 icon, even though the mp3 file cannot be actually downloaded. Users with basic computer skills can easily record the audio renedering and thus obtain the mp3 file anyway.

Max

[carlos]

Currently, "ext" icon templates exist for pdf, midi, mp3, and Lylipond files. So, I would propose to use them in lieu of the generic "net" icon wherever applicable. The "add work" scripts may automatically select the appropriate icon when the corresponding conditions are detected.

Max, I'm not sure I understood your suggestion; some editors have pdf/midi/source files on their sites but don't wish to deep-link them to CPDL (using the "ext..." icons). I think that the "net" (globe) icon fits perfectly in this case. It might be confusing to use an extpdf icon that instead of opening a pdf, redirects the user to an external site.

[carlos]

Mandy, let me update you with the current (or alternate) syntax of a couple of templates:

{{Cat|SSAAT}} ===> {{Vcat|SSAAT}}

Template Vcat is specific for categorizing voicings. When used, it allows the work to be locatable by the Multi-Category Search tool, complementing the functionality of the template Voicing.

{{MultiVoicing|5|n=2|1st=SSAAT|2nd=AATTB}}<br> ===> {{Voicing|5|SSAAT, AATTB}}<br>

MultiVoicing is intended for works with multiple number of voices involved (e.g. a 4vv section and another 5vv section). When the number of voices is the same, template Voicing may be used instead.

{{top}} / {{middle}} / {{bottom}} ===> {{top}} / {{mdl}} / {{btm}}

The short forms are aliases that can be more easily typed, but the long forms are preferred for their legibility.

{{Text|Latin}}
<poem>
...
</poem>

{{Translation|English}}
<poem>
...
</poem>

are equivalent to

{{Text|Latin|
...
}}

{{Translation|English|
...
}}

{{LnkTxt|Quem vidistis}} ===> {{LinkText|Quem vidistis}}

LnkTxt was deprecated and its functionality was incorporated into template LinkText.

[choralia]

some editors have pdf/midi/source files on their sites but don't wish to deep-link them to CPDL (using the "ext..." icons). I think that the "net" (globe) icon fits perfectly in this case.

My proposal is to use the "ext..." icons also in the case of shallow linking, so that the user is also informed about the file type(s) supposedly available on the external website.

Max

[uptoncp]

My proposal is to use the "ext..." icons also in the case of shallow linking, so that the user is also informed about the file type(s) supposedly available on the external website.

But then I'll click the link, thinking it'll take me straight to a PDF, and I'll find a list instead; and there will be multiple links to the same page for different file formats. Better, I think, to encourage listing of the available formats after the single generic link icon.

[CHGiffen]

I tend to agree with Upton.

Chuck