22
It woul be nice to develop a way so that it was possible to install the same module several times in the same site and each one could have a separate set of tables.
Even better,
develop the ability to set a different theme to a particular module. So you could change info on the fly and may be it is not needed to make many copies of the same site.
Even better,
develop the ability to set a different theme to a particular module. So you could change info on the fly and may be it is not needed to make many copies of the same site.
23
Editing HTML on the web is wish list feature that everybody claims.
But I would like to point on my wish.
I would like that html editig be preformed on a different window. (blank window with the html editor)
This simple issue results in:
1. XOOPS can tell any module what editor to use.
2. Plenty of room to concentrate in other fields.
3. no wasted time rendering editors when not needed.
you can show a preview of the page, and if want to edit it click, open the selected editor and save.
In preferences you can tell the editor you want to use for HTML at the XOOPS level or the module level...
What do you think?
But I would like to point on my wish.
I would like that html editig be preformed on a different window. (blank window with the html editor)
This simple issue results in:
1. XOOPS can tell any module what editor to use.
2. Plenty of room to concentrate in other fields.
3. no wasted time rendering editors when not needed.
you can show a preview of the page, and if want to edit it click, open the selected editor and save.
In preferences you can tell the editor you want to use for HTML at the XOOPS level or the module level...
What do you think?
24
No matter what editor is beeing used I think that it is not a good policy to include and editor on the same window where other data is beeing proceced.
For example: Wf-sections uses the spaw editor.
I woul prefer thar all data bur the page itself would be displayed... then if I want to edit the content of the html. It should have a button that calls a new window with whatever editor be configured at the XOOPS core level.
This way of implementing the editor have very much advantages. Any field containig html text coul be directly called and worked out without spending time on rendering an editor than many times is not as fast as it should be.
you can concentrate on the other fields and not wait until all the toolbars are redrawn.
I saw this strategy on a mailing software and I really think is worth thinking on it.
Jorge
For example: Wf-sections uses the spaw editor.
I woul prefer thar all data bur the page itself would be displayed... then if I want to edit the content of the html. It should have a button that calls a new window with whatever editor be configured at the XOOPS core level.
This way of implementing the editor have very much advantages. Any field containig html text coul be directly called and worked out without spending time on rendering an editor than many times is not as fast as it should be.
you can concentrate on the other fields and not wait until all the toolbars are redrawn.
I saw this strategy on a mailing software and I really think is worth thinking on it.
Jorge
25
I have been attacked this morning by a worm.
Not really sure of the cause. My hosting company is working on it, but it seems that a strong security issue must be handled
Jorge Barrero
Not really sure of the cause. My hosting company is working on it, but it seems that a strong security issue must be handled
Jorge Barrero
26
I suggest to use the most simple module for this purpouse.
The contact module (the one that comes with xoops).
The reason is simple. It is simple enough to document it, to review and to train people on how to use smoke tests and so on.
Even we can modify what ever, do some enhacements on the module just to make it fit the standard, and then on use it as a reference.
Probably we have to add some fetures that include the usage of the data base (for example to choose from a list of posible contacts).
A very simple module would be ease to explain to newbies, and will not be a distraction on the core process.
Jorge
The contact module (the one that comes with xoops).
The reason is simple. It is simple enough to document it, to review and to train people on how to use smoke tests and so on.
Even we can modify what ever, do some enhacements on the module just to make it fit the standard, and then on use it as a reference.
Probably we have to add some fetures that include the usage of the data base (for example to choose from a list of posible contacts).
A very simple module would be ease to explain to newbies, and will not be a distraction on the core process.
Jorge
27
On the road map I would like to consider the "other non english languages". Some modules behave bad or don't follow the XOOPS rules for translations.
28
I agree ,with the language issue.
Ussualy english only coders understimate this fact.
QA should have a way to make translations and language in general consistent.
Is very confusing if you use two different words in separate module for the same purpose.
Something like a Bank of terms shoul be needed
Ussualy english only coders understimate this fact.
QA should have a way to make translations and language in general consistent.
Is very confusing if you use two different words in separate module for the same purpose.
Something like a Bank of terms shoul be needed
29
Macintosh User Guide Interface is a good example of how creating a common set of expected behaviors helped finnal users. A good example is the submit button (I have found modules with different names meaning the same thing).
Basically all this Ideas point to one point. QA must start defining those standards and probably and testing protocols. If this is done right, testing would be a piece of cake.
Basically all this Ideas point to one point. QA must start defining those standards and probably and testing protocols. If this is done right, testing would be a piece of cake.
30
I have been thinking for a while about themes.
I love the idea to have a way to modify my CSS within Xoops.
An example of how this can be acomplished is here:
http://www.easterpig.com/demo/easysite/manage/edit.php
A funcionality that could "call" a css, edit some parameters (on a module or a theme).
Then every module should have a standard option to use its own css or use the actual theme or XOOPS default.
Web master could expand capabilities. One theme could have lots of variants, and each module (even each block) could select what to use.
How does it sound?
I love the idea to have a way to modify my CSS within Xoops.
An example of how this can be acomplished is here:
http://www.easterpig.com/demo/easysite/manage/edit.php
A funcionality that could "call" a css, edit some parameters (on a module or a theme).
Then every module should have a standard option to use its own css or use the actual theme or XOOPS default.
Web master could expand capabilities. One theme could have lots of variants, and each module (even each block) could select what to use.
How does it sound?
Login
Search
Recent Posts
Who's Online
Donat-O-Meter
| Stats | |
| Goal: | $100.00 |
| Due Date: | Apr 30 |
| Gross Amount: | $0.00 |
| Net Balance: | $0.00 |
| Left to go: | $100.00 |
 |
|