The use of "tags" is a nice alternative. But you'll need a way to
employ them.
d
On Sun, Aug 31, 2008 at 2:24 PM, Dennis Brown <[EMAIL PROTECTED]>
wrote:
Hello,
I have given some thought about different ways a Glossary could be
used. The straight alphabetic listing, and the search terms have
already been discussed. However, another one would be the ability to
sort the list based on different sort criteria. For instance the
official Amibroker functions list has two way to view it, either
alphabetic or by functional category. I find both useful at
different
times. However, many times, I would like to have some additional
functional categories, and we will be adding new categories that are
not just functions to the Glossary.
It seems to me that we need to have "columns" that represent other
sort categories in addition to a column for search terms.
Name, Description, AB min version#, Main Category, Sub Category, Alt
Category, related Names, search terms
It is easy to generate the list with just commas for columns and
spaces for multiple terms. Although tabs for columns and commas for
multiple terms is an option, it does not make the text version as
readable.
It would be easy to do this in a spread sheet format or a table
format. The real trick would be to display the list formatted based
on the criteria without having to display everything. Trivial to do
with a program, but I am not sure how this could be done on the UKB
other than presorting it all the different ways and displaying them
all. Of course that makes for a lot more work to update the UKB
entry.
Of course, now we would need a list of categories to use.
I would like to hear other thoughts or suggestions about this.
Best regards,
Dennis
On Aug 30, 2008, at 11:49 PM, Dennis Brown wrote:
> Hi reinsley,
>
> You have a good suggestion. Once we get the basic list together,
if
> someone wants to add a new item it would certainly be appropriate
to
> bring it up in this thread for now. That way it could be defined
> right on the spot and then added to the Glossary. I doubt the
> Glossary will be ably to be modified directly by anyone except the
> owner of the post once it goes into the UKB. We would need a Wiki
> type database to be able to do collaborative editing. A master
list
> should be available in one place in any case so someone else
could use
> it locally for searches in some other context.
>
> Best regards,
>
>
> On Aug 30, 2008, at 1:26 PM, reinsley wrote:
>
>>
>> Hello Dennis
>>
>> The glossary is a cornerstone. Great idea !
>>
>> I suggest to keep a place for acronyms.
>>
>> Maybe as a way of doing to add entries, somebody that does not
know
>> the meaning of a word or of a functionnality could add the word in
>> the
>> list.
>> Later an advanced user will feel free to add pedagogical
>> explanations.
>> Or many users will fill out the entrie.
>>
>> Best regards
>>
>>
>> --- In [email protected], Dennis Brown <[EMAIL PROTECTED]> wrote:
>>>
>>> Keith,
>>>
>>> Here is what I would suggest. We only work on the first 10 items
>>> collaboratively on-line here to start. We need to get good
exposure
>>> for this initially to get lots of good ideas from the list.
>>>
>>> I will be happy to keep a text file of all the changes and
upload it
>>> to the files section if needed and attach it to the post at each
>>> logical round of changes. Of course anyone can attach a text
file
>>> to
>>> the email version of this post which I and anyone who uses the
email
>>> option will get.
>>>
>>> Lets leave the formatting out until we get a round of feedback on
>>> that. The first 10 should stimulate ideas for how we should
format
>>> the entries to make them most useful.
>>>
>>> Some initial discussion will help solidify the overall specs of
the
>>> final format.
>>>
>>> Tuzo and Mike,
>>>
>>> You suggested using Google docs to make a collaborative effort
more
>>> efficient. I like the idea if this was an independent project
>>> with a
>>> dedicated team. However, there are some things beyond just the
end
>>> result to accomplish here.
>>>
>>> 1. I would like to have this collaborative effort done in full
view
>>> of the community and the watchful eye of Tomasz. This is
somewhat
>>> of
>>> an experiment and it can serve as a model to inspire future
>>> community
>>> wide collaboration on other projects with a wide benefit. If
there
>>> is
>>> awkwardness, let's see if we can work around it, or demonstrate a
>>> need
>>> for additional ways for the community to interact productively.
Of
>>> course it would work better in a PHP Forum environment, but lets
>>> work
>>> with what we have now.
>>>
>>> 2. Suggestions should come from anyone. Even if they only
want to
>>> participate for just a single entry on the whole project. Having
>>> too
>>> much hidden away (out of site, out of mind) would deprive the
>>> project
>>> of good input.
>>>
>>> 3. EVERYONE will benefit from seeing each and every AFL or
general
>>> AmiBroker term defined in front of them again. Think of it as an
>>> opportunity for new and old to review all the things available
and
>>> what they are good for.
>>>
>>> I am not the worlds greatest organizer, and I may have a
tendency to
>>> have my eye on the moon while seeing how high I can jump. I you
>>> think
>>> I am wrong about this approach (I acknowledge it is a bit
awkward)
>>> speak up and let's find a better way. :)
>>>
>>> Best regards,
>>> Dennis
>>>
>>> On Aug 30, 2008, at 12:07 AM, Keith McCombs wrote:
>>>
>>>> Sounds good to me.
>>>>
>>>> However, is there somewhere we could have a document that we
could
>>>> all collaborate on without the text getting all garbled up by
>>>> Yahoogroups, adding carriage returns, line feeds, and >? I
believe
>>>> there is some way to do this -- just don't know what that way
is.
>>>>
