I'm very much a dilletante programmer (I had some training at university but by no means a complete degree in the subject). So, while I think my code is stable and reasonably efficient, I am aware that I tend to program first and think later (too much thinking often gets in the way of getting the job done is often my attitude) with the result that as each major revision of wikindx develops, the code is in danger of getting more fragmented and scrappy. To deal with this, I've always used the major revision numbers (from 0.99 to 1.0, from 1.x to 2.0 and 2.x to 3.0) to trawl through the code, removing duplications, increasing efficiency and documenting classes and functions.
WIKINDX3 has reached the stage where I'm starting to think of WIKINDX4. In addition to the points raised above, I'm thinking about the major change of making wikindx even more modular than it is.
Wikindx already has a plug-in architecture but I would like to expand this so that wikindx has a small core with many of the functions it currently has becoming plug-in modules. Candidates for the latter include the word processor, import and export from and to a variety of formats (bibtex, Endnote, RTF, HTML, RIS etc.), statistics, RSS feeds and so on. The core code would consist of managing bibliographic data and metadata and handling multiple users.
I have a couple of reasons for doing this. Firstly, WIKINDX is recognized as one of the more powerful, fully-featured OS programs available and this is likely to be a factor in users choosing it. However, I often come across forum posts stating that the user decided to go for something else simpler because wikindx did too much and was too complicated to use. Making wikindx modular, would give a compact, uncluttered core to download for those requiring a simple-to-use program doing only so much while those who require the extra features can download and install plug-in modules as they wish. Secondly, while I have had others come forward with plug-in modules they have developed (OK, one has come forward), I'm hoping that a move towards a more modular model will encourage third-party plug-in development.
Additional and major features I'm thinking of for WIKINDX4 include wiki-like reversion and multiple, word processor authoring.
Comments (and, of course, developers wishing to help) on the above are welcome.
Mark.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You might also consider, expanding the templating system and separating html output from content. Right now it seems pretty complicated to change the information displayed on different pages. You´d have to modify the php code directly, which - of course - would mean you encounter problems when trying to upgrade the system.
Timo
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the feedback. That's a good idea and something that's been at the back of my mind for some time. There may be a limit to how far this can be taken but it is something that could be investigated. Are you talking about this in relation to, for example, chosing not to display certain components on a page?
Mark.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It´s not only hiding certain components, but positioning them differently on the page as well. Then it would be easier to create completely new designs or incorporate WIKINDX in existing projects.
Another suggestion (depending on how much you´re planning to change for the next version):
One might think about creating an ajax enhanced interface. I guess, one could simplify, for example, the process of adding new resources, if there´s only one screen or removes currently irrelevant elements.
Timo
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, positioning on the page can be done with the template system I'm using. There may be limits to this though. Given that every page of wikindx is a new page with often different components, I can't feasibly create a new template for each possibility. What I suppose you're talking about is breaking down the current 'content' component of the template system even further into optional components which may or may not be used on certain pages. To clarify this, can you provide an existing example of a reasonably cluttered page and how you would categorize and label the major components please?
Ajax -- I'm a javascript hacker and, as noted in a post in the other forum, my most recent javascript developer has now left (in fact I'm now the only developer again). Ajax implementation would need someone experienced in that area.
Mark
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I know it´d be quite a load of work to switch completely to templates and get rid of the HTML class. But with a template engine like smarty for example it should be possible to move all logic concerning the presentation of the information to templates. I don´t know, if the engine you´r using is comparable to smarty and could manage that kind of task.
Generally I´ve got the impression, there´d be a limited set of pages in WIKINDX (e.g. list of resources, detail view of a resource, different search pages and so on) - although sometimes with varying components for a given page.
Concerning your question, I can´t give you a precise answer. Currently I´m not trying to discard specific components, but rearrange some information as I´m trying to embed WIKINDX into another project. The HTML table used for listing resources, for example, breaks my layout. So I´m going to remove the "popularity" information in the right column and probably some other stuff. To do that, I´ve got to modify the php code, as this presentation logic isn´t embeded in a template. I´m aware that these are very specific problems as I´m not using a default stand-alone installation. But to me it still seems an interesting idea to enhance the templating abilities of WIKINDX.
Another idea: Maybe you could switch to an database abstraction layer like adodb and support different databases. I know you´ve experimented with that some time ago. Maybe you had some success with that?
BTW: Despite all my critical comments here, I really like WIKINDX. That´s why I´m using it. :-)
Timo
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I had absolutely no success whatever with using adoDb. It's extremely convenient to use certain of MySQL's unique queries and functions and this proved to be the problem. Additionally, I'm dependent upon someone else coming forward to take this on as I'm unfamiliar with the specific requirements of other databases. I understand, for example, that postgresql requires some functions I implement to be compiled in C. I have written the SQL class with a view to making the code flexible enough to work with other SQL databases but it doesn't seem to have worked so far or to have spurred someone else to take it that little bit further. I do use adoDb for managing database upgrades and this works well.
Re templating, it's the varying components for a class of page that may be the problem. However, what you want can be better supported than it is now. I'm aware that my implementation of tables can be a little confusing.
Mark.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sorry I lost contact with you - wikindx3, as it is, is a great accomplishment. As others have noted a wikindx4 approach might include an "ajax enhanced interface". Although your main js developer has left - I wanted to suggest you take a look at jquery (a javascript library) - as such it is a meta-language (leveraging standard javascript) - but in a very intuitive way. From my own understanding of your experience and knowledge - i would guess that the jQuery library would be easy for you to harness (better than me - hehe) Just wnated to add this idea to your toolset. JQuery is growing fast - just where it might be applicalbe to wikindx4 - is an unknown - but nonetheless - since you THE primary developer - a day or two of experimenting with it - might lead to new ideas - in your own mind. In effect the entire DOM is capable of being changed - modified - which might tie into your modular apprach - thinking for wikindx4. And as an aside - to let everyone else know - a big thanks for the number of hours of work you applied to the beginning stages of a CMS hook.
cheers & all best
-john weare-
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2007-12-23
Hi Mark,
>>However, I often come across forum posts stating that the user decided to go for something else simpler because wikindx did too much and was too complicated to use.
..this one closely matches my view. I have tried several times to using WIKINDX3 more routinely, but I get stuck on the rather tedious 'add' process every time. I've been looking around several times, but it is very difficult to find the perfect product - and yours is still the most complete! Not too much - just too complicated.
The one single most valuable rewrite would be the 'new resource' process. If this could be compressed to one page after the selection of type (..or better: enable type switching) it would be great! ... of course same goes for 'edit resource'.
I have tried to look into the related php files - but it is far beyond me to figure out what is going on there. A few suggestions to acomplish more compact look:
- always display 3 lines for 'creators' a.o. and let users fill in as needed. Show in 'compact table with only one line og heading (now would be shown i 5 separate input lines with own heading line) - add a '+' for user to add more creators
- show only one entry i selector boxes (creators and others), or let user select numbers in preferences
- kill the damned tables!!!
Another 'smart' thing to do - would be enabling using WIKINDX as at Joomla! module. Joomla! is preading wildly, and lots of product offer 'bridges' that allow them to integrate completely into Joomla! SMF (forum) for instance..
Again - I'm only slightly into php - but it seems the current menu structure could nicely match the way Joomla! works.
This could allow You to focus more on core functions - leaving user administration / templating / menu administration to Joomla! funtionality. Also there could be ways to benefit from included editor, pdf genrators and other..
Again - I stills find WIKINDX to be the most complete product out there, but again and again I'm stopped by the 'new' and 'edit' layout...
Hope You an use this!
Frank
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the feedback Frank. The input of creators is the big problem. If I have one page after the selection of resource type, how do I differentiate between and allow the user to add in authors, editors, series editors, translators etc.? As it currently is, there's just one extra page inserted between resource type selection and the last form to allow the user to choose. For the main functions of wikindx, I try to steer clear of javascript because of the no. of university desktop installs I've seen where javascript is disabled. So I don't think javasctip would be much use here.
Re Joomla. Since about v. 3.6.5, there has existed an interface to allow integration between wikindx and content management systems and, currently, I'm aware of one for Moodle and one for phpwcms. Naturally, I can't be expected to write the required interface for each CMS but the interface does make it simple enough.
Mark
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2007-12-23
>>As it currently is, there's just one extra page ...
If one check 'add to collection' another page is inserted...
But the main problem is actually the layout of the new / edit page. It scrolls on forever!
If I look at generated page source it is table after table... Fewer tables - and aligned fields would improve much on this - as would the ability to limit list boxes.
..I have fidled around with list boxes - and managed to 'limit' the array in on instance - but the list box itself is still a total of 6 lines.
Where CAN i modify box-lines..? I would like only 3 lines - or better: turn it into a select box with a dropdown list - is this only possible using javascript ??
>> interface to allow integration...
I know. But only to 'substitute' tags with WIKINDX content as I understand.
>> I can't be expected to write the required interface
No, of course not. It was ment as a suggestion to let you focus on core functionality - letting the CMS handle all the general stuff...
For instance: would it be possible to call WIKINDX like 'http://..../wikindx3/index.php?action=adminConfigureDisplay' and not display menus?? That would allow me to use Joomla! to display menustructures, and initiating the selected function in a IFRAME window.
Then 'only' CSS and user cookie would be an issue in integrating seemlesly in Joomla!
Frank
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2007-12-24
Hi,
...sometimes it is difficult to describe - so I decided to do at little design.
The difference is subsatntial, but the changes are small - I have only commented lines in the original - and changed a few sequences.
The selctbox was easily made as dropdown - just remode the 'size' parameter.. Onlys this does not work in 'multiple' select boxes.. Never the less - I like the more compact design.
I cleaned out som tables - which might not be needed - but at least it made the resulting code a litle clearer..
I hope You can see my meaning using this as an example..
Merry X-mas
Frank
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, that is more compact. I'm back home in a few days so if you can leave your example up I'll do some work on it for the next version. Thanks for the effort and have a good christmas,
Mark
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2007-12-25
..I'll leave them on-line.
And another point: If You put something in the empty 'class' keyword - like 'names_table', 'publisher_table' and so on it would enable the user to have more detailed control of design using CSS.
Frank
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Currently in CVS: more visually compressed new/edit resource form following (more or less) your example. BTW -- the 'extra/noise' tables you've noted are required because of the use of tables in content.tpl and other template files. Your example displays fine in Firefox but is messed up in IE (v6) which is less forgiving of missing TABLE tags.
Mark
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2008-01-01
Hi Mark,
.. checked it out, and in my opinion it looks much better this way!! Most of my resources fit in one page now :-)
Don't know how much work it was to change this, but there are many places where such changes could improve usability a lot..
A good guideline is to aim at enabling the user to do all basic operations completing no more than one page (without scrolling) - and storing selections to be used as preferences for next lookup.
I like the 'resource'/'browse' pages very much - they provide you with all categories, and gives a very intuitive acces to resource lists.
On the other hand the 'resource'/'list' access would gain usability if it just went on to display list using latest selections, and let the user change sorting criteria from a dropdown list.
Another nice feature would be a 'very quick search' as one search field on top of list page, enabling user to enter a few words for global search...
Recently I started testing of Joomla 1.5, and I'll try to 'wrap' my wikindx into the menus...
Frank
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
How large is a page? i.e. what's your monitor resolution?
I don't understand your point about gaining usability in the resource/list page?
I would have thought the way to integrate wikindx into another HTML page would be to remove the upper-order HTML tags from the appropriate template files.
Mark
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2008-01-01
>> How large is a page? i.e. what's your monitor resolution?
..monitor: 1280*1024, but as I prefer running in a window max would be about 1024 x 768. Of course the page restrictions will allow for using smaller fonts (which I'm experimenting with in templates).
>> I don't understand your point about gaining usability in the resource/list page?
As to resource / list. First You present the list criteria page - then the list.. My point is: I often use same criterias, so it would be nice to skip the page for selection and just use my latest.
You could then provide a dropdown to change selection along with a new (very quick) search field above the list. Usability would improve 1) by skipping the selection page, and 2) by allowing the user to change citerias / sorting without leaving the list page..
>> ... to remove the upper-order HTML tags from the appropriate template files.
That would be part of it. My plan is to create menu entries in Joomla in the form "http://kratvej28c.dk/wikindx3/index.php?action=resourceNew" opening the resulting page in a wrapper (that is: IFRAME) - and stripping WIKINDX header and menu structures.
This should work and integrate WIKINDX in my new Joomla! site - only leaving the problem of multiple CSS's and the user log-on / administration....
Frank
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I took the 'vert' template, and stripped it down to a new one called 'wrapper', and use this as default template..
The idea is to add a few more direct commands to allow daily use and administration.
I've done a few tests with the full setup, and seems pop-ups work. There are problems with your fixed width of entry fields in add/edit resource. They 'break' the iframe... It would apparently be better to set field width based on %!
Don't know about word processor - I have newer used it..
Frank
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2008-01-05
...both. Besides (almost) emptying the .tpl files, I also removed #header, #content #footer and #nav from .css.
You can access the files here: http://kratvej28c.dk/files/WIX/
As to log-on: To recognize Joomla logon, you would 'only' have to recognize the joomla user cookie - still using own cookie for storing settings and such (.... I guess)
Frank
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2008-01-05
..forgot. THX for the links - yes thats about the same I plan for step one. I would like to enabled adding / editing embedded also, and I guess it's where I'll get into problems..
Frank
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Do you know what your joomla cookie is called and what the fields stored in it are? If so, it should not be too difficult to change core/cookie/COOKIE.php to read a joomla cookie if it exists.
It's complicated by having to have the joomla username:password combination duplicated in wikindx. What happens if there's one logon for joomla but multiple logons for wikindx? (Or vice versa?)
Mark
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Comments on thoughts below most welcome.
I'm very much a dilletante programmer (I had some training at university but by no means a complete degree in the subject). So, while I think my code is stable and reasonably efficient, I am aware that I tend to program first and think later (too much thinking often gets in the way of getting the job done is often my attitude) with the result that as each major revision of wikindx develops, the code is in danger of getting more fragmented and scrappy. To deal with this, I've always used the major revision numbers (from 0.99 to 1.0, from 1.x to 2.0 and 2.x to 3.0) to trawl through the code, removing duplications, increasing efficiency and documenting classes and functions.
WIKINDX3 has reached the stage where I'm starting to think of WIKINDX4. In addition to the points raised above, I'm thinking about the major change of making wikindx even more modular than it is.
Wikindx already has a plug-in architecture but I would like to expand this so that wikindx has a small core with many of the functions it currently has becoming plug-in modules. Candidates for the latter include the word processor, import and export from and to a variety of formats (bibtex, Endnote, RTF, HTML, RIS etc.), statistics, RSS feeds and so on. The core code would consist of managing bibliographic data and metadata and handling multiple users.
I have a couple of reasons for doing this. Firstly, WIKINDX is recognized as one of the more powerful, fully-featured OS programs available and this is likely to be a factor in users choosing it. However, I often come across forum posts stating that the user decided to go for something else simpler because wikindx did too much and was too complicated to use. Making wikindx modular, would give a compact, uncluttered core to download for those requiring a simple-to-use program doing only so much while those who require the extra features can download and install plug-in modules as they wish. Secondly, while I have had others come forward with plug-in modules they have developed (OK, one has come forward), I'm hoping that a move towards a more modular model will encourage third-party plug-in development.
Additional and major features I'm thinking of for WIKINDX4 include wiki-like reversion and multiple, word processor authoring.
Comments (and, of course, developers wishing to help) on the above are welcome.
Mark.
You might also consider, expanding the templating system and separating html output from content. Right now it seems pretty complicated to change the information displayed on different pages. You´d have to modify the php code directly, which - of course - would mean you encounter problems when trying to upgrade the system.
Timo
Hi TImo,
Thanks for the feedback. That's a good idea and something that's been at the back of my mind for some time. There may be a limit to how far this can be taken but it is something that could be investigated. Are you talking about this in relation to, for example, chosing not to display certain components on a page?
Mark.
It´s not only hiding certain components, but positioning them differently on the page as well. Then it would be easier to create completely new designs or incorporate WIKINDX in existing projects.
Another suggestion (depending on how much you´re planning to change for the next version):
One might think about creating an ajax enhanced interface. I guess, one could simplify, for example, the process of adding new resources, if there´s only one screen or removes currently irrelevant elements.
Timo
Hi Timo,
Yes, positioning on the page can be done with the template system I'm using. There may be limits to this though. Given that every page of wikindx is a new page with often different components, I can't feasibly create a new template for each possibility. What I suppose you're talking about is breaking down the current 'content' component of the template system even further into optional components which may or may not be used on certain pages. To clarify this, can you provide an existing example of a reasonably cluttered page and how you would categorize and label the major components please?
Ajax -- I'm a javascript hacker and, as noted in a post in the other forum, my most recent javascript developer has now left (in fact I'm now the only developer again). Ajax implementation would need someone experienced in that area.
Mark
I know it´d be quite a load of work to switch completely to templates and get rid of the HTML class. But with a template engine like smarty for example it should be possible to move all logic concerning the presentation of the information to templates. I don´t know, if the engine you´r using is comparable to smarty and could manage that kind of task.
Generally I´ve got the impression, there´d be a limited set of pages in WIKINDX (e.g. list of resources, detail view of a resource, different search pages and so on) - although sometimes with varying components for a given page.
Concerning your question, I can´t give you a precise answer. Currently I´m not trying to discard specific components, but rearrange some information as I´m trying to embed WIKINDX into another project. The HTML table used for listing resources, for example, breaks my layout. So I´m going to remove the "popularity" information in the right column and probably some other stuff. To do that, I´ve got to modify the php code, as this presentation logic isn´t embeded in a template. I´m aware that these are very specific problems as I´m not using a default stand-alone installation. But to me it still seems an interesting idea to enhance the templating abilities of WIKINDX.
Another idea: Maybe you could switch to an database abstraction layer like adodb and support different databases. I know you´ve experimented with that some time ago. Maybe you had some success with that?
BTW: Despite all my critical comments here, I really like WIKINDX. That´s why I´m using it. :-)
Timo
Hi Timo,
I had absolutely no success whatever with using adoDb. It's extremely convenient to use certain of MySQL's unique queries and functions and this proved to be the problem. Additionally, I'm dependent upon someone else coming forward to take this on as I'm unfamiliar with the specific requirements of other databases. I understand, for example, that postgresql requires some functions I implement to be compiled in C. I have written the SQL class with a view to making the code flexible enough to work with other SQL databases but it doesn't seem to have worked so far or to have spurred someone else to take it that little bit further. I do use adoDb for managing database upgrades and this works well.
Re templating, it's the varying components for a class of page that may be the problem. However, what you want can be better supported than it is now. I'm aware that my implementation of tables can be a little confusing.
Mark.
WIKINDX4 will probably also require PHP5 and will no longer work with PHP4.
Mark
Cheers Mark,
Sorry I lost contact with you - wikindx3, as it is, is a great accomplishment. As others have noted a wikindx4 approach might include an "ajax enhanced interface". Although your main js developer has left - I wanted to suggest you take a look at jquery (a javascript library) - as such it is a meta-language (leveraging standard javascript) - but in a very intuitive way. From my own understanding of your experience and knowledge - i would guess that the jQuery library would be easy for you to harness (better than me - hehe) Just wnated to add this idea to your toolset. JQuery is growing fast - just where it might be applicalbe to wikindx4 - is an unknown - but nonetheless - since you THE primary developer - a day or two of experimenting with it - might lead to new ideas - in your own mind. In effect the entire DOM is capable of being changed - modified - which might tie into your modular apprach - thinking for wikindx4. And as an aside - to let everyone else know - a big thanks for the number of hours of work you applied to the beginning stages of a CMS hook.
cheers & all best
-john weare-
Hi Mark,
>>However, I often come across forum posts stating that the user decided to go for something else simpler because wikindx did too much and was too complicated to use.
..this one closely matches my view. I have tried several times to using WIKINDX3 more routinely, but I get stuck on the rather tedious 'add' process every time. I've been looking around several times, but it is very difficult to find the perfect product - and yours is still the most complete! Not too much - just too complicated.
The one single most valuable rewrite would be the 'new resource' process. If this could be compressed to one page after the selection of type (..or better: enable type switching) it would be great! ... of course same goes for 'edit resource'.
I have tried to look into the related php files - but it is far beyond me to figure out what is going on there. A few suggestions to acomplish more compact look:
- always display 3 lines for 'creators' a.o. and let users fill in as needed. Show in 'compact table with only one line og heading (now would be shown i 5 separate input lines with own heading line) - add a '+' for user to add more creators
- show only one entry i selector boxes (creators and others), or let user select numbers in preferences
- kill the damned tables!!!
Another 'smart' thing to do - would be enabling using WIKINDX as at Joomla! module. Joomla! is preading wildly, and lots of product offer 'bridges' that allow them to integrate completely into Joomla! SMF (forum) for instance..
Again - I'm only slightly into php - but it seems the current menu structure could nicely match the way Joomla! works.
This could allow You to focus more on core functions - leaving user administration / templating / menu administration to Joomla! funtionality. Also there could be ways to benefit from included editor, pdf genrators and other..
Again - I stills find WIKINDX to be the most complete product out there, but again and again I'm stopped by the 'new' and 'edit' layout...
Hope You an use this!
Frank
Thanks for the feedback Frank. The input of creators is the big problem. If I have one page after the selection of resource type, how do I differentiate between and allow the user to add in authors, editors, series editors, translators etc.? As it currently is, there's just one extra page inserted between resource type selection and the last form to allow the user to choose. For the main functions of wikindx, I try to steer clear of javascript because of the no. of university desktop installs I've seen where javascript is disabled. So I don't think javasctip would be much use here.
Re Joomla. Since about v. 3.6.5, there has existed an interface to allow integration between wikindx and content management systems and, currently, I'm aware of one for Moodle and one for phpwcms. Naturally, I can't be expected to write the required interface for each CMS but the interface does make it simple enough.
Mark
>>As it currently is, there's just one extra page ...
If one check 'add to collection' another page is inserted...
But the main problem is actually the layout of the new / edit page. It scrolls on forever!
If I look at generated page source it is table after table... Fewer tables - and aligned fields would improve much on this - as would the ability to limit list boxes.
..I have fidled around with list boxes - and managed to 'limit' the array in on instance - but the list box itself is still a total of 6 lines.
Where CAN i modify box-lines..? I would like only 3 lines - or better: turn it into a select box with a dropdown list - is this only possible using javascript ??
>> interface to allow integration...
I know. But only to 'substitute' tags with WIKINDX content as I understand.
>> I can't be expected to write the required interface
No, of course not. It was ment as a suggestion to let you focus on core functionality - letting the CMS handle all the general stuff...
For instance: would it be possible to call WIKINDX like 'http://..../wikindx3/index.php?action=adminConfigureDisplay' and not display menus?? That would allow me to use Joomla! to display menustructures, and initiating the selected function in a IFRAME window.
Then 'only' CSS and user cookie would be an issue in integrating seemlesly in Joomla!
Frank
Hi,
...sometimes it is difficult to describe - so I decided to do at little design.
I select new resource (book) amd 2 og each person category. The resulting page can be seen here:
http://kratvej28c.dk/wikindx3/new.ex.html
I saved the source and made some corrections to make it more 'user friendly' (at least in my oppinion..). Look here:
http://kratvej28c.dk/wikindx3/new.ex.fja.html
The difference is subsatntial, but the changes are small - I have only commented lines in the original - and changed a few sequences.
The selctbox was easily made as dropdown - just remode the 'size' parameter.. Onlys this does not work in 'multiple' select boxes.. Never the less - I like the more compact design.
I cleaned out som tables - which might not be needed - but at least it made the resulting code a litle clearer..
I hope You can see my meaning using this as an example..
Merry X-mas
Frank
Hi Frank,
Yes, that is more compact. I'm back home in a few days so if you can leave your example up I'll do some work on it for the next version. Thanks for the effort and have a good christmas,
Mark
..I'll leave them on-line.
And another point: If You put something in the empty 'class' keyword - like 'names_table', 'publisher_table' and so on it would enable the user to have more detailed control of design using CSS.
Frank
Hi Frank,
Currently in CVS: more visually compressed new/edit resource form following (more or less) your example. BTW -- the 'extra/noise' tables you've noted are required because of the use of tables in content.tpl and other template files. Your example displays fine in Firefox but is messed up in IE (v6) which is less forgiving of missing TABLE tags.
Mark
Hi Mark,
.. checked it out, and in my opinion it looks much better this way!! Most of my resources fit in one page now :-)
Don't know how much work it was to change this, but there are many places where such changes could improve usability a lot..
A good guideline is to aim at enabling the user to do all basic operations completing no more than one page (without scrolling) - and storing selections to be used as preferences for next lookup.
I like the 'resource'/'browse' pages very much - they provide you with all categories, and gives a very intuitive acces to resource lists.
On the other hand the 'resource'/'list' access would gain usability if it just went on to display list using latest selections, and let the user change sorting criteria from a dropdown list.
Another nice feature would be a 'very quick search' as one search field on top of list page, enabling user to enter a few words for global search...
Recently I started testing of Joomla 1.5, and I'll try to 'wrap' my wikindx into the menus...
Frank
Hi Frank,
How large is a page? i.e. what's your monitor resolution?
I don't understand your point about gaining usability in the resource/list page?
I would have thought the way to integrate wikindx into another HTML page would be to remove the upper-order HTML tags from the appropriate template files.
Mark
>> How large is a page? i.e. what's your monitor resolution?
..monitor: 1280*1024, but as I prefer running in a window max would be about 1024 x 768. Of course the page restrictions will allow for using smaller fonts (which I'm experimenting with in templates).
>> I don't understand your point about gaining usability in the resource/list page?
As to resource / list. First You present the list criteria page - then the list.. My point is: I often use same criterias, so it would be nice to skip the page for selection and just use my latest.
You could then provide a dropdown to change selection along with a new (very quick) search field above the list. Usability would improve 1) by skipping the selection page, and 2) by allowing the user to change citerias / sorting without leaving the list page..
>> ... to remove the upper-order HTML tags from the appropriate template files.
That would be part of it. My plan is to create menu entries in Joomla in the form "http://kratvej28c.dk/wikindx3/index.php?action=resourceNew" opening the resulting page in a wrapper (that is: IFRAME) - and stripping WIKINDX header and menu structures.
This should work and integrate WIKINDX in my new Joomla! site - only leaving the problem of multiple CSS's and the user log-on / administration....
Frank
Hi Frank,
I'll see what I can do about the list page -- basically have both list criteria and list on the one page for efficiency.
I can't see that link you provide because I don't have access rights.
Synchonized log-on will be problematic.
Can you have an iFrame within an iFrame (i.e. will the word processor work?)? Will the wikindx pop-ups work?
Mark
Hi Mark,
..sorry about the link. It was just as example on the command I would use.
You can see my fist attempt here:
http://kratvej28c.dk/joomla/index.php?option=com_wrapper&view=wrapper&Itemid=63
I took the 'vert' template, and stripped it down to a new one called 'wrapper', and use this as default template..
The idea is to add a few more direct commands to allow daily use and administration.
I've done a few tests with the full setup, and seems pop-ups work. There are problems with your fixed width of entry fields in add/edit resource. They 'break' the iframe... It would apparently be better to set field width based on %!
Don't know about word processor - I have newer used it..
Frank
Hi Frank,
Was that mainly the .tpl files you edited?
Here are some other examples similar to your's:
http://www.msh.univ-nantes.fr/documentation/zal/zal/index.php
http://mistakengoal.com/wikindx3/
http://web.cher.ubc.ca/ktdatabase/index.php
Mark
...both. Besides (almost) emptying the .tpl files, I also removed #header, #content #footer and #nav from .css.
You can access the files here: http://kratvej28c.dk/files/WIX/
As to log-on: To recognize Joomla logon, you would 'only' have to recognize the joomla user cookie - still using own cookie for storing settings and such (.... I guess)
Frank
..forgot. THX for the links - yes thats about the same I plan for step one. I would like to enabled adding / editing embedded also, and I guess it's where I'll get into problems..
Frank
Do you know what your joomla cookie is called and what the fields stored in it are? If so, it should not be too difficult to change core/cookie/COOKIE.php to read a joomla cookie if it exists.
It's complicated by having to have the joomla username:password combination duplicated in wikindx. What happens if there's one logon for joomla but multiple logons for wikindx? (Or vice versa?)
Mark