On Tue, Nov 4, 2008 at 6:33 AM, alinome.net <[EMAIL PROTECTED]> wrote: > > OK. By the way, I see a little terminology problem: data field vs > BoltWire field. In fact all "field" words are linked to the glossary. > That can be a bit confusing for beginners. Perhaps we could use only > "data value" or "data variable" or "page data"... or remove the > "field" glossary links. I suggest to udate and grow the glossary. It > should be part of the handbook and contain all the BoltWire's terms. > But I think the automatic linking into the glossary is not needed > (besides the potential confusions).
This is a legitimate point. Though I'm not sure how to fix it. All variables are essentially field/value pairs, whether you are talking about data, info, page, system, or skin vars. I don't think we could call them anything else. Label? On the other hand we could perhaps change our notation for boltwire fields. Perhaps calling them sites or wiki's. This is a very different kind of thing. And while it would require some updating of docs seems more plausible. I'm open to suggestons. I like the semantic sense of farm, barn, and field together, and fields certainly suggest the "growing" nature of wiki's in general. But I'm not set in stone on that--even after all this time. Could we have multiple "farms" in a single BoltWire installation? That might work--but think of the confusion when searching the archives! Or perhaps we can just go with farm, barn & sites/wikis. I guess I like sites best. Also, on the subject of metaphors, as I was thinking about the solutions section, I found myself repeatedly thinking about PmWiki's cookbook/recipe system. I really loved that, and never felt "resources" or "solutions" had near the same appeal. If we are going to reorganize the solutions section at some point into some grand, single hierarchy, I'd be inclined to rename it along the same line: cookbook/recipe. A radical idea but easy enough to do. I'd be willing to invest the trouble. Should we stick with what we got? Imitate PmWiki? Or perhaps there's a comparable alternative? I remember early on arguing for the use of simple metaphors for these kind of things, and still feel strongly about it, but I also recognize the more clear our nomenclature, the easier and more precise our docs will become. That's definitely something worth working on! Cheers, Dan --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "BoltWire" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/boltwire?hl=en -~----------~----~----~----~------~----~------~--~---
