Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo
we have separate apps for global project. Let's say this app-module.
XE on cubrid.org, MediaWiki on wiki.cubrid.org, Wordpress on blog.cubrid.org, and phpbb on forum.cubrid.org and each is running on separate database. It means, we cannot provide the correct search results to users depending on which module the users search. Now Esen is trying to move and consolidate tutorials from cubrid.org to wiki however it cannot resolve our problem. I think we should have google search or other search engines to provide correct results.
Related to the separate module issues, I want users to stay longer and look around our contents more.
for instance, even if updates are made on forum.cubrid.org by users and us, visitors on cubrid.org cannot see any change as long as they click to forum.cubrid.org. Any update on each module should be gathered and displayed on the front page or other proper page so that users can see any movement of our project.
What do you guys think?
As we have agreed, I will make a column on cubrid.org home page so that visitors can see the dynamic changes in other sites. Currently we already have the latest activities from Blog, News, cubrid.org itself, and Wiki. So, I am planning to create a similar column on the right to display LATEST FORUM POSTS, LATEST FEATURE REQUESTS.
If any more ideas, let me know.
1. I really don't see a problem in having different modules on cubrid.org: xe, wiki, forum, blog and having different searching engines for each of them. When user wants to search something in the documentation (for example) he/she will load cubrid wiki and search there. Each section of the site (module) contains a separated information that would be easier to be found in that particular section. So in my opinion, at least at this moment, I don't think that an unified search engine for all the modules will help. But if you consider, we will search for a solution regarding it. Please let us know your opinion.
2. I am not sure if showing on the homepage latest posts or comments or updates from blog or wiki would be a good thing. Maybe we should have a separate page for these kind of information (something like "latest updates"). Homepage should only contains news like: "new php connector for 5.3 available" (this is something that attracts user's attention) and not all the latest actions, posts or articles on cubrid.org. I think that would be too much.
Please let us know your feedback.
I agree with your first statement. Concerning the latest actions, I think we need to show users we are alive. We have to make every visitor to continue browsing our sites (wiki, cubrid.org, blog, forum). We have to display some attractive titles so that to catch their eyes and make them look into and discover something new. In OS projects the latest blogs and news are displayed on the home page. Me personally, I never click on the "News" tab. If there is something on the home page, I might be attracted and click on it, but nothing more. I usually don't look at News, blogs, or whatever. I assume that if there is something special they would display it on the first page. This is what I think. If anyone thinks the other way, please let me know.
The only thing that might be a concern for us, is the overwhelming amount of information on the home page. That may be, but I hope the nice user interface will cover such drawbacks. I hope we have an attractive and at the same time informative home page. If you think there is something missing or something too much on the home page, let me know. I will reconsider the contents.
In the top of the list with most visited pages of cubrid.org are: homepage, about, migrating with scriptella, downloads. In my opinion most of our visitors (at this moment) are new on cubrid.org (visiting for the very first time). For this type of visitors I think it is not so important to see the last actions(latest updates). It is not so important to see that the site is "alive". They need to understand what is CUBRID, why to choose CUBRID, key features, supported APIs, etc.
Of course there are visitors who are not for the first time on cubrid.org (or other module: wiki, blog, forum). And you are right, for this type of visitors we need to make them spend as much as possible time browsing the latest articles, posts, etc.
However we need to have one version for both of them: a compromise between showing many information with latest updates for second type of users and showing less information but oriented on the users who access cubrid.org for the first time.
So my point is to have in mind both type of users when making changes on the homepage of cubrid.org
I have uploaded CUBRID 2008 R3.0 EN Integrated Search.rar (web based documentation with searching capability, not PDF) to sf.net.
Please use it.
Thank you for the manual, Esen. We will take a look at the differences with the old version and decide how to proceed.
I have uploaded the new version for CUBRID R3.0 Documentation.
1. Please download it again.
2. Please totally remove the current CUBRID Manual from http://cubrid.org/manual and replace it with this latest version. Please, make sure the uploaded manual looks identical and the searching works as well.
If there are any problems, please let me know.
I uploaded the manual here: http://www.cubrid.org/manual/r3.0/ and removed the old one.
The link to the manual from the Documentation section now leads to the Wiki->Manuals.
I would like to propose several actions for CUBRID Manual updates on Wiki. This is not all, later if new ideas come, you also provide your thoughts.
1. Assume there is deprecated function some_function() which has a dedicated page on Wiki called Some Function. In order to reflect the updates/changes, let's do the following:
a) do not delete or move the current page.
b) create a new page called Some Function R2.1.
c) Copy all the contents of the existing page and save it.
d) In this current Some Function page, alter the contents as required. At the end of the page provide a link to the deprecated Some Fucntion R2.1 page. Save it.
The rest cases, let's think later.
There is one more thing I wanted to ask Catalin.
On Wiki we have a page "Cubrid 2008 R2.1 manual" with this link http://wiki.cubrid.org/index.php/Cubrid_2008_R2.1_manual. I don't want visitors to think that the current tutorials is outdated. So, I propose not to write the version numbers for the page names. OK?
Concerning this Manual case, if you agree, I will rename it and make sure all other pages, which link to this Cubrid 2008 R2.1 manual, are updated with the new link.
Reply me soon.
Regarding your post no 11 here is my answer:
Our plan is to start adding the R3.0 manual to wiki and there will be different sections: one for R2.1 manual and one for R3.0 manual. But until then, you are right, probably the current name of that page will just make the users believe that the manual is outdated. So you can replace it for now and we will rename it after we finish adding the new manual R3.0 (probably in 2-3 weeks). Also "2008" creates the sensation of an outdated manual and it should be removed too (but that is different story).
We will organize the manual with a better link structure now for example we will have wiki.cubrid.org/index.php/manuals/CUBRIDR2.1/some_page . With this we will not have to go through all the pages and name them with CUBRIDR3.0.
We are doing this now for CUBRID R2.1 the same will be done for CUBRIDR3.0.
please refer to the Korean manual site. It is on cubrid.com and not only the latest version but also every version manual it hs.
However, they have a common url, http://www.cubrid.com/online_manual/new/index.htm, which always re-directs to the latest version.
Daniel and Catalin,
Chaning to wiki.cubrid.org/index.php/manuals/CUBRIDR2.1/some_page sounds a bit confusing for right now. In this case I have several questions.
1. You want to create as if different "folders" for each manual, right?
2. In that case, it seems like you do not have to make any updates. You just upload every new manual to a new "folder" and we will have all versions. Right?
2. If, so. Everything sounds good, as we will not have to manually go through each page and patch the updates. But, there is one issues with this. When I search for some term, which manual will it show me first? Or which results will it show at all? The results should be the latest.
Please clarify your actions before you start.
Catalin and Daniel,
There is another thing to consider. I have already made so many editing in Wiki, i.e. in CUBRID Manual. Especially, I made so many changes for Tutorials. So, possibly many of those pages are unchanged, and some have updates in version 3.0. But for most pages I don't want to have two versions.
What I mean is I have updated the 2.1 version, which actually has not been changed in 3.0. So, when you upload, you will upload kind of older version, as I have edited the latest, so, this leads to much work. You have to be sure that I haven't updated the 2.1 version.
Any ideas for this issue?
Also, I would like to say, let's first clarify all our actions what, when, and how, then start updating the manuals, otherwise, if we wanted something else, we would have changed in vain.
We've noticed that you created a redirection for cubrid.org/manual to http://wiki.cubrid.org/index.php/CUBRID_Manuals. Like I said in the previous post, Search Engines have indexed already the Old manual. Look at this link http://wiki.cubrid.org/index.php/CUBRID_Manuals/whnjs.htm. This is what happens with the Google Search Links.
So. could you please upload 3.0 Web manual (with searching tool) to the old place (cubrid.org/manual). Which means you have to remove the redirection as well. Laura is finishing the 3.0 Release Notes, and she has many links which refer to cubrid.org/manual. If we do not upload online manual to that location, all links will be broken in the Release Note. So, please fix it.
In all other places where we mention the CUBRID Manual, we will provide Wiki links, which will be the main reference. But just for this case: SE and Release Notes, let's leave cubrid.org/manual.
R3.0 manual is now available at the following address http://www.cubrid.org/manual/
Regarding your post number 15, here is our answer:
We will create the redirect for wiki.cubrid.org/manuals/ to the latest version.
Regarding the structure it is exactly like on cubrid.com: http://wiki.cubrid.org/index.php/CUBRID_Manuals/cubrid_2008_R2.1_manual and http://wiki.cubrid.org/index.php/CUBRID_Manuals/cubrid_2008_R3.0_manual .
Regarding item 17:
Yes we will simulate a folder link structure, and we won;t have to go through all the pages to rename them.
The search shows the date of the articles it finds so it is easy to identify the latest articles. Also it shows the full path (CUBRID Manuals/cubrid 2008 R2.1 manual/Performance Tuning/Parameters) so users can easily see it is a CUBRID 2008 R2.1 manual article.
I don't understand the problem at item 17, could you please explain in detail?
1. First of all, thanks a lot to Rienzi for the corrected code. The reason for the typo in PHP code could be the fact that CUBRID API section in the documentation has not been maintained for a long time, about two years. So, as we agreed with Catalin (https://sourceforge.net/projects/cubrid/forums/forum/1168043/topic/3769803) last time, if you see some strange things, make changes and let us know as well by posting on this forum.
2. The comment to Daniel's post #21.
Daniel, the search results seem to be very confusing. Why don't we show only the page Title distinctively, and the full URL underneath, very similar to Google search results. If necessary you could just display the categories underneath as well, i.e. the page belongs to CUBRID Manuals, CUBRID Manager, PHP API, ….
3. The comment to Daniel's post # 22.
Catalin has already solved this issue. What I wanted is to leave www.cubrid.org/manuals link which should point to Original Web CUBRID Documentation, because, first, some pages has already been indexed by Searching engines, second, Laura has been referring to most pages through the Release Notes, and she needed that original Documentation. So, finally, Catalin, reported that you have fixed what we needed.
Regarding your last comment # 2. on Daniel's post #21 please see below my comment:
The current search result seems quite OK for me (I am trying to look from the user's perspective). I think that showing full path of the article (ex: "CUBRID Manuals/cubrid 2008 R2.1 manual/API Reference/cci connect") would be more self explaining for the user to see the version of the manual (2.1/3.0) than showing the category. We can remove the size of the document and the date time of the last update of that article because it is not too relevant for the user.
We can also change the behavior of Media Wiki that we use such that only the Title and the URL should be displayed (also category can be added) as you said. Also we can add a media wiki extension (Google Custom Search Engine). However we will need about 3 days for these changes.
Please let us know how to proceed with this.
1. OK. Leave it as is. Remove the size and date indicators.
2. Also the text underneath the URL seems messed up. Either think how to improve or remove it as well.
3. If the Full URL is displayed the Category is not needed.
4. Google Custom Search: Do we need it? Will it totally replace the current one? What are the pros and cons?
I found a problem with long URLs. Check out the Tutorials Category. You will notice that these long URLs mess up the contents. Consider it.