Page 4 of 6
Re: Reorganizing History Data
Posted: 01 Apr 2011 17:25
by admin
j_c_hallgren wrote:admin wrote:While I now tend to think that "Embed" should replace "Merge" (which for me connotes something irreversible) in the interface, I have the following idea for marketing purposes: decentralized functionality.
Sorry, but to me that term (decentralized functionality) means absolutely nothing in this context...I still think that combined or consolidated are better terms for this since they don't imply being irreversible in all cases.
With merged catalogs XY goes a step towards being a file-based project management tool for distributed teams, a networked file manager. This should be told somehow.
Re: Reorganizing History Data
Posted: 01 Apr 2011 17:33
by j_c_hallgren
admin wrote:With merged catalogs XY goes a step towards being a file-based project management tool for distributed teams, a networked file manager. This should be told somehow.
Agreed and understood...but I think that needs to be somewhat separate from how this specific feature is described...and the networked thing can't be done in a couple of words, at least no two words I can think of...a few words, maybe...but "merged" catalogs can be done in two words, I'm sure.
Re: Reorganizing History Data
Posted: 01 Apr 2011 17:36
by Stefan
admin wrote:With merged catalogs XY goes a step towards being a file-based project management tool for distributed
teams, a networked file manager. This should be told somehow.
Cool! Like the old
Lirpa from Ekoj?
Re: Reorganizing History Data
Posted: 01 Apr 2011 17:42
by admin
j_c_hallgren wrote:admin wrote:With merged catalogs XY goes a step towards being a file-based project management tool for distributed teams, a networked file manager. This should be told somehow.
Agreed and understood...but I think that needs to be somewhat separate from how this specific feature is described...and the networked thing can't be done in a couple of words, at least no two words I can think of...a few words, maybe...but "merged" catalogs can be done in two words, I'm sure.
I think the main problem is the word "catalog" itself, because a newbie will not know what it means in XY. Functionally it's kind of a scrollable macro toolbar, a freely programmable area in the UI, where complex things can be reduced to single clicks. Now with embedded catalogs (trying the other term now...

) writing the complex parts can be outsourced to savvy coders, and all you need to do is to "embed the wisdom" (or e.g. the boss's orders). And many users can embed the same remote catalog. You could even abuse it as a new communication channel, XY as a chat machine...
Re: Reorganizing History Data
Posted: 01 Apr 2011 17:44
by admin
Stefan wrote:admin wrote:With merged catalogs XY goes a step towards being a file-based project management tool for distributed
teams, a networked file manager. This should be told somehow.
Cool! Like the old
Lirpa from Ekoj?
? You mean "eine der schrecklichsten vulkanischen Waffen." ?

Re: Reorganizing History Data
Posted: 01 Apr 2011 17:55
by j_c_hallgren
admin wrote:I think the main problem is the word "catalog" itself, because a newbie will not know what it means in XY.
But given the traditional definition of the word ("
a complete enumeration of items arranged systematically with descriptive details), they should have some idea of what it could be...and remember: They might have to read a least a paragraph to understand it...there are some things in my lite/limited vers of Photoshop that I still don't understand even after a few years

Re: Reorganizing History Data
Posted: 02 Apr 2011 10:19
by admin
j_c_hallgren wrote:RalphM wrote:admin wrote:BTW, marketingwise I find "Catalog Merging" a bit pale. Any buzzy suggestions anybody...?
You didn't like the first name I gave it then? "Cascading Catalogs"
I was thinking of Consolidated -or- Combined as suggested words.
Combine is not bad IMO. Combined Catalogs has a good sound. But combine connotes equal weight of the combined parts, whereas we have a clear parent-child relation here, which is better conveyed by Embed. Embed, however, does not describe the particular "mechanics of merging" (where the merged items are sorted into their existing categories) as good as the term "merge". Merge is perfect apart from the fact that is sounds irreversible. So it's a "reversible merge". Maybe that's something so revolutionary that there isn't a word for it yet...
Consolidate... I don't really know that word.

And looking it up brings up a variety of meanings...
Re: Reorganizing History Data
Posted: 02 Apr 2011 16:36
by j_c_hallgren
admin wrote: But combine connotes equal weight of the combined parts,
Not quite true...you
combine flour and butter and eggs in a recipe and they don't have the same weight...which makes me think about this word: "
blended catalog" since one definition of blend is "
to combine into an integrated whole".
whereas we have a clear parent-child relation here,

Huh? We do? That would require a multi-level catalog which we don't have, AFAIK. Each catalog has a single parent/child setup and when brought together, the parents act as brother/sister, I think.
Re consolidate:
http://www.merriam-webster.com/dictionary/consolidate
Which mentions other possible words:
Joined or
United
And
http://dictionary.reference.com/browse/consolidate which defines it as
to bring together (separate parts) into a single or unified whole; unite; combine: They consolidated their three companies.
so it seems like a good word for this situation.
To me, consolidated has somewhat of a higher 'class' to it than combined and sounds more techy.
Re: Reorganizing History Data
Posted: 02 Apr 2011 18:39
by admin
j_c_hallgren wrote:admin wrote: But combine connotes equal weight of the combined parts,
Not quite true...you
combine flour and butter and eggs in a recipe and they don't have the same weight...which makes me think about this word: "
blended catalog" since one definition of blend is "
to combine into an integrated whole".
whereas we have a clear parent-child relation here,

Huh? We do? That would require a multi-level catalog which we don't have, AFAIK. Each catalog has a single parent/child setup and when brought together, the parents act as brother/sister, I think.
Re consolidate:
http://www.merriam-webster.com/dictionary/consolidate
Which mentions other possible words:
Joined or
United
And
http://dictionary.reference.com/browse/consolidate which defines it as
to bring together (separate parts) into a single or unified whole; unite; combine: They consolidated their three companies.
so it seems like a good word for this situation.
To me, consolidated has somewhat of a higher 'class' to it than combined and sounds more techy.
I meant parent-child in a more general sense, like planet and moons. There is the one catalog that's loaded (the parent) and all the currently merged catalogs; it's different roles.
I *guess* that non-mother tongue speakers will have more problems with consolidate than with merge, or embed, or combine, or join.
"Joined" is not bad... less irreversible than merged, isn't it?
Re: Reorganizing History Data
Posted: 02 Apr 2011 18:50
by j_c_hallgren
admin wrote:I meant parent-child in a more general sense, like planet and moons. There is the one catalog that's loaded (the parent) and all the currently merged catalogs; it's different roles.
I believe that concept would be hard to explain...maybe using terms primary and secondary (or similar) would be more appropriate when it's not a true parent/child because when I think parent/child, it's a nested situation like tree and this is more of a flat/parallel situation it seems.
I *guess* that non-mother tongue speakers will have more problems with consolidate than with merge, or embed, or combine, or join.
That could be true...so then I'd go for combine of those four choices...partially because it begins with "C" and thus goes with "C"atalog nicely.
"Joined" is not bad... less irreversible than merged, isn't it?
Could be..I've seen unilities that "join" files and they produce a single output file so the inputs are still unchanged and that's what we're doing in a way.
Re: Reorganizing History Data
Posted: 02 Apr 2011 19:23
by admin
j_c_hallgren wrote:"Joined" is not bad... less irreversible than merged, isn't it?
Could be..I've seen unilities that "join" files and they produce a single output file so the inputs are still unchanged and that's what we're doing in a way.
Yes, Join and Split is a common pair. So join can be reversed. And it has a positive ring to it, related to the team work concept that's behind the Catalog Merging feature. And, last not least, Joint Catalogs abbreviates to JC, Mr j_c_hallgren!

Re: Reorganizing History Data
Posted: 03 Apr 2011 00:14
by Stefan
It's hard to find an good idea, ...some more to think about
Code: Select all
temporary catalog merging TCM
temporary catalog joining TCJ
non-permanent catalog merging NPCM
non-destructive catalog blending NDCB
temporary catalog mixing TCM
temporary catalog melting TCM
Re: Reorganizing History Data
Posted: 03 Apr 2011 09:18
by admin
Stefan wrote:It's hard to find an good idea, ...some more to think about
Code: Select all
temporary catalog merging TCM
temporary catalog joining TCJ
non-permanent catalog merging NPCM
non-destructive catalog blending NDCB
temporary catalog mixing TCM
temporary catalog melting TCM
TCM is known as Traditional Chinese Medicine. This might lead to confusion...

Re: Reorganizing History Data
Posted: 03 Apr 2011 21:06
by admin
admin wrote:j_c_hallgren wrote:"Joined" is not bad... less irreversible than merged, isn't it?
Could be..I've seen unilities that "join" files and they produce a single output file so the inputs are still unchanged and that's what we're doing in a way.
Yes, Join and Split is a common pair. So join can be reversed. And it has a positive ring to it, related to the team work concept that's behind the Catalog Merging feature. And, last not least, Joint Catalogs abbreviates to JC, Mr j_c_hallgren!

Join is out (because of the usage "join the club", which makes "join the catalog" ambiguous).
My current favorite is
combine. Speak up in the next 12 hours to object...

Re: Reorganizing History Data
Posted: 04 Apr 2011 12:14
by admin
admin wrote:admin wrote:j_c_hallgren wrote:"Joined" is not bad... less irreversible than merged, isn't it?
Could be..I've seen unilities that "join" files and they produce a single output file so the inputs are still unchanged and that's what we're doing in a way.
Yes, Join and Split is a common pair. So join can be reversed. And it has a positive ring to it, related to the team work concept that's behind the Catalog Merging feature. And, last not least, Joint Catalogs abbreviates to JC, Mr j_c_hallgren!

Join is out (because of the usage "join the club", which makes "join the catalog" ambiguous).
My current favorite is
combine. Speak up in the next 12 hours to object...

Argh, more problems! If you compare the following statements, I *think* (not being a born English speaker) that the first one has a clearer reference/meaning in the way it is intended:
This item is from a Merged Catalog. Any edits are not retained across sessions.
This item is from a Combined Catalog. Any edits are not retained across sessions.
"Merged Catalog" seems to refer to the catalog that was merged into the existing one, whereas "Combined Catalog" rather refers to the combination of both (all) combined catalogs. Right?