Revision history for GUIImprovements
Additions:
<Paul>
Ok, no problem. Just thought I'd ask as I didn't see it mentioned.
Ok, no problem. Just thought I'd ask as I didn't see it mentioned.
Additions:
<Phil>
Smarty adds an abstraction layer - personally I am opposed to additional abstraction as this compromises readability and consequently maintainability of the code. KISS applies throughout webERP if I have had anything to do with the code.
Smarty adds an abstraction layer - personally I am opposed to additional abstraction as this compromises readability and consequently maintainability of the code. KISS applies throughout webERP if I have had anything to do with the code.
Deletions:
Additions:
<Paul - Templates?>
Has there been any thought or suggestion of possibly using a template engine, such as [[http://www.smarty.net/ Smarty]], with webERP?
</Paul>
Has there been any thought or suggestion of possibly using a template engine, such as [[http://www.smarty.net/ Smarty]], with webERP?
</Paul>
Additions:
The caveat to this is of course how far do we go with javascript - my feeling is that we should use it only for interactivity - site navigation and data validation before the script gets submitted. We should avoid large libraries of javascript functions that add 50k (arbitrary) or more to a page. Also, the server side php should allow the system to be run even when javascript is not available at the browser.
Deletions:
Additions:
~- We have more capable developers on the team with experience in javascript now
Deletions:
Additions:
~- Phil doesn't know it and foray's into it yielded inconsistent results on different browsers
~- Concerns about adding overhead to the size of scripts to download negatively impacting performance
~- We have more capable developers on the team not
~- Javascript and browsers have evolved to a greater level of maturity
~- Many if not most are using broadband connections to the internet and thus adding a few kb to scripts is not a concern.
~- Concerns about adding overhead to the size of scripts to download negatively impacting performance
~- We have more capable developers on the team not
~- Javascript and browsers have evolved to a greater level of maturity
~- Many if not most are using broadband connections to the internet and thus adding a few kb to scripts is not a concern.
Deletions:
~-> Concerns about adding overhead to the size of scripts to download negatively impacting performance
~-> We have more capable developers on the team not
~-> Javascript and browsers have evolved to a greater level of maturity
~-> Many if not most are using broadband connections to the internet and thus adding a few kb to scripts is not a concern.
Additions:
<Phil - Background>
webERP has been developed entirely without javascript until now because:
webERP has been developed entirely without javascript until now because:
Deletions:
Additions:
The visual apperance of webERP also needs work - this I think can be done mostly with css and laying out forms in a more appealing and logical format. With navigation and error trapping avoiding the requirement for back and excessive error message on submitting forms - if the message pops up at the time the entry is made this is more intuitive to deal with adding greatly to the usability of webERP
Additions:
The caveat to this is of course how far do we go with javascript - my feeling is that we should use it only for interactivity - site navigation and data validation before the script gets submitted. We should avoid large libraries of javascript functions that add 50k (arbitrary) or more to a page.
Deletions:
Additions:
</Phil>
Additions:
<Phil - Background>webERP has been developed entirely without javascript until now because:
~-> Phil doesn't know it and foray's into it yielded inconsistent results on different browsers
~-> Concerns about adding overhead to the size of scripts to download negatively impacting performance
To some extent it is possible that both of these reasons for not having javascript may no longer be valid.
~-> We have more capable developers on the team not
~-> Javascript and browsers have evolved to a greater level of maturity
~-> Many if not most are using broadband connections to the internet and thus adding a few kb to scripts is not a concern.
The caveat to this is of course how far do we go with javascript - my feeling is that we should use it only for interactivity - site navigation and data validation before the script gets submitted. We should avoid large libraries of javascript functions that add 20k or more to a page.
~-> Phil doesn't know it and foray's into it yielded inconsistent results on different browsers
~-> Concerns about adding overhead to the size of scripts to download negatively impacting performance
To some extent it is possible that both of these reasons for not having javascript may no longer be valid.
~-> We have more capable developers on the team not
~-> Javascript and browsers have evolved to a greater level of maturity
~-> Many if not most are using broadband connections to the internet and thus adding a few kb to scripts is not a concern.
The caveat to this is of course how far do we go with javascript - my feeling is that we should use it only for interactivity - site navigation and data validation before the script gets submitted. We should avoid large libraries of javascript functions that add 20k or more to a page.
Additions:
====User Concerns====
[[http://www.nabble.com/To-javascript-or-not-to-javascript-td20445872.html Ongoing Discussion on mailing list]]
Concerns raised include: (comments truncated - follow link above for details)
"It is common for JavaScript enhanced sites behave differently or not at all in Mozilla, IE, Google Chrome and Safari. Maintaining functional
code in the ever changing browser designs will require more time and effort from the main programmers of webERP..."
"I'm questioning the need to add a layer of complexity in both development and maintenance of webERP. Function and speed are most important to me."
[[http://www.nabble.com/To-javascript-or-not-to-javascript-td20445872.html Ongoing Discussion on mailing list]]
Concerns raised include: (comments truncated - follow link above for details)
"It is common for JavaScript enhanced sites behave differently or not at all in Mozilla, IE, Google Chrome and Safari. Maintaining functional
code in the ever changing browser designs will require more time and effort from the main programmers of webERP..."
"I'm questioning the need to add a layer of complexity in both development and maintenance of webERP. Function and speed are most important to me."
Additions:
Add other libraries under consideration. For code submissions, please put all JS code includes in //javascript// folder.
Deletions:
Additions:
- GUI - use [[http://tango.freedesktop.org/ Tango Desktop]] icons?