ILIAS open source Forums

Aktuell kann über die Suche lediglich in wenigen Bereichen gesucht werden. Keine Möglichkeit besteht z.B. zur Suche in SCORM-Modulen oder Glossaren ....

Ferner sollte die Möglichkeit bestehen, Elemente aus dem Suchmenü auszublenden (Beispiel: DigiLib wird nicht verwendet - warum sollte jemand danach suchen?)

Gruß

Norbert

It would be useful, if the search function was able to search objects in the repository by name.

The search function should list all objects of which the name matches the query. This should happen regardless of the object type.

You can search within glossaries now, but why is the search function for glossaries not at the same place, as all other search functions?

If you click 'search' (the prominent link in the title frame), you should also be able to search within glossaries, I think.

(was Mantis #120 -feature-, reported by Jens Kistler, Zürich)

agreed. I suggest to simplify the search function.
1. The average user does not know what the difference between Metadata and Fulltext is. So forget about this.
2. The average user does not want a seperation within search (e.g. learning modules, glossaries, tests, groups whatever). So forget about this too.
3. We all know that there are cases where we need exactly these detailed items, so one should implement something like "Advanced Search". (like Google does)

When this would be implemented only a textfield where I enter the keyword and a button "search" would be needed. Then one should implement this in the top navigation (like all other pages do).

I agree: having a simple titlebar search, which searches everything, and an "advanced search", which can be more precisely defined, is the best idea.

In both cases, the search results should be sorted by type: Glossary results, Learning Module results, SCORM Module results, Discussion Forum results, and so on.

Who is currently working on this? I would like to collaborate with them. I have written similar search functions in other projects.

Here are my plans for enhanced Search function. Suggestions and comments are welcome.

Move Search command to far right of menu bar, after Administration.

Add text box to Search command menu item. Change the function of the Search button to submit the contents of the text box to the search engine.

Change the behavior of the default Search menu item to search both metadata and content of all searchable item types.

Change search results page to remove item type checkboxes.

Change search results page to add link to Advanced Search.

Create Advanced Search page with item type checkboxes and possibly other search-related settings.

Add search capability to other item types, particularly:

Category
Course
Chat
Learning Module HTML
Learning Module SCORM/AICC
Glossary
Survey
Media Pool

Comments? Suggestions?

We also plan to revise/extend the search feature (see recent jour fixe minutes). Stefan Meyer will work on this, if you plan to do any coding, please contact him to prevent any double work.

A first step will be just to search through all titles and descriptions (table object_data). We also want to separate the meta data search to an advanced meta data search form (that contains filters for all lom elements). But this will need a revision of the meta data structure as well. We hope to get this funded and imlpemented for 3.5.0.

If a simple search form should be added to the top frame the limited space in the top frame has to be handled carefully. But the major question is the behaviour of such a search form. If really all meta data and content of all searchable objects should be searched, the default search would be of worse performance than most of the advanced search requests, which e.g. would only search through the content of certain object types (e.g. learning modules or forums only) or only search meta data.

Regards
Alex

Actually, one of the reasons I selected the Search function as my next effort was because it appeared that no one else was working on it. However, I would be happy to discuss it with him: in what topic on this forum is he posting his plans? (This was the most relevant topic I could find to post my own plans.)



The current "Search" link would be replaced by a text box and a smaller "Search" button. There is sufficient room.



That can be discussed. Perhaps the default search would only search metadata? That would be relatively fast, and the user could then select "metadata and all content" in the advanced search.

That would not be the expected behaviour. A user would expect that a search located in the top frame would be a global search. If we want to provide a search in the top frame it should at least include an object type selection list (learning module, forum, ...) or a similar filter that would speed up the request.

I've made a small paper concerning the revision of the meta data handling and the search capabilities of ILIAS. We hope to get it funded for version 3.5.0. Any comments are appreciated.

Advanced Search and Meta Data Revision

I agree, the expected behaviour would be for it to be a global text search. But you said (correctly) that it would be slower, so I offered a suggestion to make it faster. Either it works globally, and slower, or it searches a smaller subset of the data, and is faster. We may choose one or the other. For myself, I would prefer the gobal, but slower, search. Which would you prefer? I will work to implement whichever the ILIAS team prefers.



That is a bad idea, for two reasons:

1) It will require more space in the title area. As you have pointed out, functions implemented in the title area should use space efficiently, because there is a small amount of space to work with.

2) It's clunky and adds complexity, which is in opposition to the entire idea of having a simple, one-click Search function. Filters and other added details are suitable to the the "advanced search", and that is how users will expect it to work.

I will also read the document you linked to.

It seems to be a reasonable plan. I only have two comments at this time.

1) I am concerned that you want to bind ILIAS to a specific version of a specific database. I think it would be wiser to move away from a specific database, through the use of a database abstraction layer such as Pear-DB or ADODB (I prefer Pear-DB, myself). This would allow the use of ILIAS on a greater variety of systems. I believe that systems should be as database-agnostic as possible.

2) The use cases describe the "Advanced Search" form, but they do not address the simple, one-click Search which experience shows us that most people will actually prefer to use. In general, I think it is better to spend more time addressing features which will be used more often.

Personally, I would prefer neither the first nor the second because both alternatives have major disadvantages. I would like to hear some other opinions on that issue.



Yes, you are right. So this wouldn't be a good solution too.

If there is another option, I have never seen it.

I will be on vacation for the next two weeks. Perhaps someone will think of something new in that time. When I return, I would like to help enhance the search, or to help implement the user annotation feature. At this time, these are the features which most interest my institution.

Implementing a database abstraction layer is an old issue. Unfortunately at the beginning of the ILIAS 3 development this concept has not been introduced. Then on the ILIAS conference in 2003 we've discussed this issue and looked for someone who could fund this, but noone wanted to do this. Today SQL-Statements are spread all over the application classes and the introduction of a database abstraction would be a huge effort, very rough estimation: about 4-5 person months of concept building, coding, changing the existing database structures and testing everything on every database. That are costs about 45.000 to 60.000 Euros.


Yes, I totally agree. If we find a good solution here, I will add it to the spec immediately.

You have my sympathy. I have this exact same problem on a project for which I am responsible.