What would you like to see in Zoom V7 - Please post your suggestions

[David]

We are currently in the process of working out what features should be in the next major release of Zoom.

We have collected a list of requests over the past 12 months, but we haven't actively solicited feedback until now.

It is already clear that we won't have time to implement everything that everyone has asked for, but we'll endeavour to implement the most in demand features.

What could be improved? What might open up new applications or markets for the product? What would need to be a new release to entice you to upgrade? Let us know.

[matt-c]

I would like to be able to tell zoom the folder the index files are stored in this line:

<ZoomASPX:ASPXSearch id="ASPXSearch" runat=server/>

i.e. add an optional parameter like src="search/indexfiles/"
So:
<ZoomASPX:ASPXSearch id="ASPXSearch" src="search/indexfiles/" runat=server/>

This would mean i could implement it in more than 1 website in a dotnetnuke portal as i could point to the different index folders for each website.

Full story is here for those interested: http://www.wrensoft.com/forum/showthread.php?t=4087

[David]

Thanks for posting. Ray already mentioned in the other thread we'd have a look at this.

[MergeThis]

Exact phrase searching in JavaScript mode?

Pretty, please?

[matt-c]

Even better would be to create a module for dnn. I think this would be a lot of work for you though but the dnn market is pretty big so could be well worth your while.

www.snowcovered.com is where most dnn modules can be found...

[Ray]

We are looking into CMS integration more seriously but it's hard to know which CMS to invest our time in as there are so many out there, and they all require a great deal of work to integrate deeply in the form of a module or add-on.

Zoom, as it is, can be made to work with most CMSes out there. But it requires a bit of work on the user's part to determine the best way of integration. Although we do our best to document what we know about this, in the form of FAQs like these:
Q. How to create a search engine for your DotNetNuke website
Q. How to create a search engine for your Moodle website
Q. How to create a search engine for your Mambo or Joomla! based website

But DNN is definitely one of the more popular requests. We'd love to get more feedback and see where the demand is (and what features are most needed). For example, most of these CMSes offer a built-in search feature - what do they lack? Presumably this is the reason you are seeking to use Zoom in place of it.

[sizbut]

Really simple but exporting categories in a form suitable for import would make me inordinately happy.

[David]

Sizbut, I know is isn't exactly what you are asking for, but you could keep a master copy of the categories list in Excel and import the list into Zoom as required. This can be done in the current release. If it was a one off job, you could also pull the data from the .zcfg file.

[cmodule00]

As mentioned previously the 'Recommended Links List' to incorporate not just the presentation of a raw link but a banner or even a form (offer) to complete.

Visitor searches 'cars' and is shown a free car insurance quote offer instead of a 'recommended link' to another page that shows the same thing.

..

[Vernon]

Database indexing: new feature request

The feature that would make Zoom a dream for content management driven web sites is the ability to read direct from database tables using SQL queries.

It would then make Zoom a contender against using Index Server for SQL Server.

Our need is to index all the content held in a database. This contents is rendered into HTML when a particular page is requested by a user on the web site. Standard CMS stuff.

To get this content indexed at the moment, we load into Zoom's configuration a no-follow URL for every record in the database we want to index. When called, this URL renders the page into simple HTML (via the CMS) and then Zoom adds it to its index. The templates are simple: we strip out complex coding and images used to render the page when a visitor requests it from the web site.

It would be so much quicker if Zoom could define a database connection string and thereby issue an SQL query; the configuration would need an option to weight the fields. Alternatively (if this would make the process easier to add), the configuration could hold a reference to an HTML template so that an HTML page could be built before being parsed in the same way as now.

I don't know, but I suspect one of the limits on Zoom's processing speed is determined by the number of simultaneous HTTP threads that can be sustained, and creating the page more directly by an SQL query would improve the speed of chewing through 100,000 or so database records. It would also not add so much load to the site itself. Adjusting the SQL query used could easily accommodate new pages recently added etc.

If there is any chance of this feature, I'd be delighted to propose more detail for consideration. We don't use an open source CMS (we have built our own), but I can see that options to read WordPress, Joomla et al could be added.

We'd love to abandon all our straight database searches, remove any use of Index Server, and just rely on Zoom.

Thanks.

Vernon

[Ray]

The feature that would make Zoom a dream for content management driven web sites is the ability to read direct from database tables using SQL queries.

This is something we have considered in the past, and it is definitely something we would consider for V7 if there is enough interest.

The big question however, is just what sort of benefits we can offer over existing solutions and the ones built into most databases.

To get this content indexed at the moment, we load into Zoom's configuration a no-follow URL for every record in the database we want to index. When called, this URL renders the page into simple HTML (via the CMS) and then Zoom adds it to its index. The templates are simple: we strip out complex coding and images used to render the page when a visitor requests it from the web site.

It would be so much quicker if Zoom could define a database connection string and thereby issue an SQL query; the configuration would need an option to weight the fields. Alternatively (if this would make the process easier to add), the configuration could hold a reference to an HTML template so that an HTML page could be built before being parsed in the same way as now.

It seems to me that if the admin/site developer is capable of writing the SQL query, they would very likely be capable of hammering out their own search function utilizing the full-text indexing capabilities of the database in question.

The problem then is that it would become a feature which is too difficult to use for the less-knowledgable user (who would need it most) and can only be used by the more knowledgeable user (who wouldn't need it).

Could you elaborate on what the built-in/manual solutions lack, or why you would prefer Zoom to do this over say, Index Server?

I don't know, but I suspect one of the limits on Zoom's processing speed is determined by the number of simultaneous HTTP threads that can be sustained, and creating the page more directly by an SQL query would improve the speed of chewing through 100,000 or so database records. It would also not add so much load to the site itself. Adjusting the SQL query used could easily accommodate new pages recently added etc.

Yes, this is true, but it seems (at this point) to be a relatively small gain (i.e. a slight decrease in server load during indexing, and indexing speed) in comparison to the complexity of implementation and end-user difficulty in setting up.

Complexities include:
- Determining how to relate a data record to a URL (simplest case would just have a ID field which we can pass to a user defined URL such as: http://mysite.com/articleid=123 but more complicated systems may require something more convoluted)
- The need for user definition of how tables or fields relate to each other to make sense of a record.
- The need for user definition of how to search/index certain fields, what to ignore, etc.
- CMS' like Wordpress and Joomla are likely to have convoluted database schemas to consider -- for us to implement a template/language that allows the user to define how to index these schemas would likely be fairly intricate, and worse when it means the end-user will have a hard time making it work.

But yes, by all means, we'd love to hear from more people who are interested in this. Please elaborate on what you are expecting Zoom to do here that isn't addressed by current solutions.

[Monday]

Regarding: "the ability to read direct from database tables using SQL queries."
I think for the most part this offers little gain except for being able to preform a real time search which may be good for some websites that are constantly being updated. The complexities of how to relate the search results back to a given page could be very daunting depending on how the website is structured.

I would like to see something similar though. Basically a web-based front end search for my database.

The end user configures zoom with
1. A connection string
2. A kind of pseudo query that defines what fields should be searched and what fields should be displayed back on the screen. Kind of like a SELECT query
3. Zoom creates a search page and the user adds it to their website

When the user does a search, zoom displays the results in a grid
(Bonus points to optionally have the ability build a link on certain fields using the values found)

Where this could become really powerful is the ability to aggregate search results for multiple database's.

I have some data that I need to search in our intranet and it can't be indexed with zoom given the way these websites are setup or they do not have a website at all, it may just be a database. I would need to create my own custom webpages and then index them with zoom. This would save me the hassle of of extra DEV work.

[Ray]

Regarding: "the ability to read direct from database tables using SQL queries."
I think for the most part this offers little gain except for being able to preform a real time search which may be good for some websites that are constantly being updated.

I think Vernon was suggesting we index the database content and perform the search within our index, not directly on the database (correct me if I'm wrong, Vernon). So that wouldn't have this benefit.

And if we were to do this, then Zoom would serve little purpose, it would just act as an interface to the database. If the user can write the SQL query to perform the real time search, then they should just as easily be able to write their own PHP script to do so.

I have some data that I need to search in our intranet and it can't be indexed with zoom given the way these websites are setup or they do not have a website at all, it may just be a database. I would need to create my own custom webpages and then index them with zoom. This would save me the hassle of of extra DEV work.

This is interesting, the idea of allowing you to create a search-based front-end to databases that are not actually currently exposed. Again the challenge here is to offer something truly beneficial and worthwhile, over something that the user could hand code.

[Texarkana Chiropractor]

Wordpress?

Any plans for Wordpress integration? Second vote would be Joomla.

[David]

Zoom already works with Wordpress sites. There are a couple of reports of this here,
http://www.wrensoft.com/forum/showthread.php?t=3133
http://www.wrensoft.com/forum/showthread.php?t=3786
(maybe we could do tighter integration however)