MS4 handbook: rename "Other frame text" to "Text in frames"
IMV, the page titled "Other frame text" is confusing as it gives the impression that there is already a page elsewhere dedicated to text in frames. My preference would be for "Text in frames".
Comments
Agreed. I think that's a holdover from a time I consider having a separate page for the title frame. And actually, really there is a bigger problem because no one really thinks "I want some text in a frame" (unless they are thinking about rehearsal marks, which of course have frames of a totally unrelated kind). Instead, people think, "I want some text not connected to a specific note or measure". A page name that suggests that - without going to far and calling it something "attached to the page" or "free floating" - would be ideal. Thoughts?
In reply to Agreed. I think that's a… by Marc Sabatella
A good choice would be "Plain Text". Sibelius (for example) uses this language to refer to the text style of "I just want some non-specific-purpose text on the page" and I've always found it to be very memorable and self-explanatory.
In reply to Agreed. I think that's a… by Marc Sabatella
Page text
Text blocks
In reply to Page text Text blocks by jeetee
I suggest "Other text". i.e.text other than what has already been described. This assumes that every type of text other than what we call "Frame text" has been described elsewhere in the article.
In reply to Agreed. I think that's a… by Marc Sabatella
Thanks for the suggestions. Let me give me comments, then let's see if we can find a consensus:
"Text in frames" - this would absolutely win if not for the fact that the word "frames" also means something completely different (the box or circle around a rehearsal mark). So it's likely to be misleading. That's a problem we also need to sovle in the actual program too!
"Plain text" - I don't see that this really helps differentiate text in a frame from text attached to a note. Sounds more like, text with no special formatting, or maybe text with no playback behavior. But, if it is a term used to main the equivalent of frame text in other programs, that is definitely a plus.
"Page text" - this comes close, although it creates the somewhat misleading impression that the text is fixed to a specific page and/or a specific position on a page. Since we don't actually have that, frame text is the closest thing we have, but what if someday we do add something more like "true" page text?
"Text blocks" - interesting choice, reminds me of how many web page builders work these days, and it's not a bad analogy. Especially when one considers you can actually stack multiple frames just as you would text blocks in Wordpress etc.
"Other text" - I can't argue with the accurateness of it, but I am concerned a person who has some idea of what they want would need to study all the rest of the page titles before concluding their case is a "none of the above" and settle for this. I'd prefer a title that you can just look at and say, "yes, that's the one I want".
With all that in mind, I think my first choice is "Text blocks", followed by "Page text". I'd pick "Text in frames" if we also got some sort of commitment to actually change the name of the other kind of frame. Other comments?
In reply to Thanks for the suggestions. … by Marc Sabatella
Un-anchored text.
In reply to Un-anchored text. by xavierjazz
"Detached text" maybe?
In reply to Thanks for the suggestions. … by Marc Sabatella
Hmm, so far I haven't seen further comments on the original set of proposals and my analysis, but I'll add my comments on the new alternate proposals. At some point, we should probably stop coming up with new proposals and just see if we can come to a consensus on on existing one :-)
"Un-anchored" text - this is somewhat accurate, somewhat not - it's anchored to a frame instead of a note, rest, or measure. But my bigger concern is that I fear it won't really mean anything to most people scanning the table of contents.
"Detached text" - similar.
"Score details text" - yes, I think this was more or less the kind of thing I had in mind when "Other frame text" came up as the place for additional text. But I'm thinking there is no real value in separating these out, as the basic content of the two pages would be identical.
So, I'd still like feedback on my comments on the existing proposals and see if we can get more than 2 people to agree on a single choice.
In reply to Hmm, so far I haven't seen… by Marc Sabatella
To explain further my suggestion:
There is a distinction between "Score details text" and "other frame text" in that the score details are populated automatically from the score properties meta data - the user doesn't need to know that frames are involved, whereas the "other text in frames" is text generated for some other purpose by the user - the "other text" part of that name - and which needs to be added to a frame - as referenced in the second part of the that name - to allow the text to be added and positioned.
Perhaps it could be referred to as "Other text (in frames)" with the parentheses indicating that the use of frames is not the main point, the main point being that this is text other than the predefined types. Or perhaps it could be "Other text - freeform (in frames)".
In reply to To explain further my… by SteveBlower
'Text Blocks' is probably the clearest choice I've seen so far, it's pretty close to what I imagine a user would have in mind when searching for how to put a block of text on the page. I'll boost for my 'Plain Text' suggestion once more though, after having seen all the other (kind of confusing IMO) suggestions.
My reasoning : if I am seeking to put words on a score that are NOT expression text, dynamics text, subtitle text, lyrics, tempo text, headers, footers, etc., my brain looks at the list of all the different types of text and says to me, "Dang it, I just want to put some plain text on my page, not any of those fancy specialized kinds of text."
The concern that it might confusingly refer to the format of the text doesn't really come into play for me because obviously text can be formatted however you want once you get it on the page.
Maybe my Sibelius usage has biased me but that particular terminology has always clicked almost instantly for me when I see it in the long list of types of text. "Oh yeah, that's the one I was looking for!"
In reply to 'Text Blocks' is probably… by Al Loast
Thanks for the comment!
I do suspect your Sibelius experience is coloring things. I think the majority of times when one thinks, "I just want plain text, not some fancy specialized type", they actually want staff text or system text. That's basically plain text for most cases. So I think if people who don't already know this term from Sibelius saw a page called "plain text", they'd think it was for what we call staff or system text.
In reply to Thanks for the comment! I do… by Marc Sabatella
You are probably right here. In fact, Plain Text is only available as a sub-option for either System Text or Staff Text in Sibelius. There are special text options for blank page text but I don't think they provide a way to place unattached text on a non-blank (music-containing) page at all. All text elements, even Title, Subtitle and Composer text objects are shown as being attached to a measure of the score.
In reply to To explain further my… by SteveBlower
While it's true that there are some different commands specifically for title etc, everything else about them is in common with ordinary frame text. And note, titles can be added to any vertical frame, not just the top frame (crucial in having multiple pieces in a single score. So, you'd need the "other" page to learn how to enter some titles. I would say, only if this page gets too long would it be worth splitting.
I do like the idea of "Other text (in frames)", I think that does help clarify. Except for the nagging issue that a frame simply doesn't mean what most users will probably assume it means, so I'd prefer not to confuse them with MuseScore terminology that conflicts with their actual expectations. It's definitely unfortunate, and we do have to live with the mess created by the ambiguous naming. Maybe being upfront about it is the best way. If so, I still like the "blocks" terminology as being the single best word I've seen to match user expectations; better than "other". So maybe "Text blocks (in frames)" or something along those lines.
In reply to While it's true that there… by Marc Sabatella
I think text blocks is a pretty good solution. I use programs that use something similar, and are clear.
In reply to While it's true that there… by Marc Sabatella
I'll go along with "Text blocks (in frames)". I admit that "Other" is a bit of a nebulous term and does require something to define what it is "other" than. "Text block" gives a more immediate picture of what the topic might be about.
In reply to While it's true that there… by Marc Sabatella
I suggested (below) renaming the property "Frame" to "Border". That would reserve the name "Frame" for the rectangular score objects. Then, "Text in frames" (or similar) becomes a possibility.
In reply to I suggested (below) renaming… by geetar
Long term, I'm in favor of options like that. But I'd say there is almost no chance of actual UI changes like that for 4.0 at this point. We need to document the software as it is, not as we hope it might be someday :-)
In reply to Long term, I'm in favor of… by Marc Sabatella
Deleted.
In reply to While it's true that there… by Marc Sabatella
You wrote:
So maybe "Text blocks (in frames)" or something along those lines.
"Text blocks (stand-alone)"
In reply to You wrote: So maybe "Text… by Jm6stringer
All the adjectives that you want to add such as "in frame", "standalone" sounds like developer things in the help title.
Just "Text block" is fine
In reply to Thanks for the suggestions. … by Marc Sabatella
What about "Generic text" or "Non-specific text"? Anyway, I like "Text blocks", "Text in frames" or "Score details text" too.
The ambiguity could be resolved by using the term "Border" (None / Rectangle / Circle) instead of "Frame".
In reply to The ambiguity could be… by geetar
As frame text consists of title, subtitle, composer, lyricisr, part name, how about calling that "Score details text" (or something less clunky) with an explanation that entering such text automatically creates a text frame. Then text added to user-created text frames could be "Other text in frames".
Late to the discussion, but I read all the comments. Was going to vote for Text block (in frames) but remembered Microsoft Office programs use "Text box", not text block. In fact there is a wikipedia page for text box https://en.wikipedia.org/wiki/Text_box
So I would go for Text box (in frames), and start the page with disambiguation about the types of frames.
Concerning the potential name change in the gui, "border" is already used in, for example, changing the colour of the frame around rehearsal marks.
The same issue appears in translations - I checked French and Spanish versions and the equivalent of "frame" is used in the same ways. I imagine a name change in the gui has to propagate through all the languages.
In reply to Late to the discussion, but… by GeoJenner
Indeed, border is already used to describe the border of the frame - but so is "frame". And yes, changing the UI is more involved, and seems out of the question right now.
I still don't have great feelings about any of these, but I think I've pretty much decided to go with simple "Text blocks". I don't think "(in frames)" is needed any more than we need "Rehearsal mark (above the staff)". The title of these pages should reflect the function, not info about where it goes. And there is info about frames in general elsewhere. Keep in mind, you can put more than just text into frames, and multiple texts per frame.
Text box is almost as good, but I feel it's more old school, and blocks is more the way modern UI's call these.
Of course, we can continue to second-guess this and still change it later, nothing is set in stone.
Thought I might as well try drafting my thoughts on the page: https://musescore.org/en/handbook/4/other-frame-text
I put my ideas below the heading scaffold. I quickly realised it's more complicated than I thought. I might delete the work before you all wake up.
I went ahead and made the title change, also updated the headings. As always, nothing is set in stone, but hopefully this helps.