Some i18n issues
Locked
 
Administrator
|
In UI, we begin to hit the Pareto principle http://en.wikipedia.org/wiki/Pareto_principle
This is a good and a bad news. It means we achieved most and to achieve the rest it will cost us (actually in our case, I'm much more confident because we actually hitted Pareto wall earlier :o) Typography Typography depends on languages. For instance in French we put a space after colons, there are other cases of course. So punctuation should be always part of labels. HTML We already discussed about not putting any HTML tags in labels. Actually we should at least not allow any < and & which will not be correctly rendered (http://www.w3.org/TR/REC-xml/#dt-chardata) I quickly noticed some problematic cases (found in French maybe ok in other languages) : ProductRedExplanation (in Product association) WebtoolsMessage2 (Webtools export) WebtoolsMessage5 (Webtools import) ManufacturingNote3 (Edit BOM) There are certainly others, just a 1st approach Thanks Jacques |
|
Jacques Le Roux wrote:
> In UI, we begin to hit the Pareto principle > http://en.wikipedia.org/wiki/Pareto_principle > This is a good and a bad news. It means we achieved most and to achieve > the rest it will cost us (actually in our case, I'm much more confident > because we actually hitted Pareto wall earlier :o) [citation needed] > Typography > Typography depends on languages. For instance in French we put a space > after colons, there are other cases of course. So punctuation should be > always part of labels. > > HTML > We already discussed about not putting any HTML tags in labels. Actually > we should at least not allow any < and & which will not be correctly > rendered (http://www.w3.org/TR/REC-xml/#dt-chardata) > I quickly noticed some problematic cases (found in French maybe ok in > other languages) : > ProductRedExplanation (in Product association) > WebtoolsMessage2 (Webtools export) > WebtoolsMessage5 (Webtools import) > ManufacturingNote3 (Edit BOM) > There are certainly others, just a 1st approach This also goes back to CSS style best practices. We shouldn't name things "ProductRedExplanation" because it implies a color. What if a stylesheet changed the text color to yellow? Then the name would not make sense. It is better to use names like "ProductHighlightedExplanation" to indicate the text is somehow different, but without specifying its attributes. -Adrian |
|
Administrator
|
From: "Adrian Crum" <[hidden email]>
> Jacques Le Roux wrote: >> In UI, we begin to hit the Pareto principle http://en.wikipedia.org/wiki/Pareto_principle >> This is a good and a bad news. It means we achieved most and to achieve the rest it will cost us (actually in our case, I'm much >> more confident because we actually hitted Pareto wall earlier :o) > > [citation needed] :D I just meaned that we are above 80% of UI accomplishment and that future percentages will cost more and more (for less and less benefits)... As simple as Jungle Rule... Jacques |
|
|
On Feb 3, 2009, at 11:04 AM, Jacques Le Roux wrote: > From: "Adrian Crum" <[hidden email]> >> Jacques Le Roux wrote: >>> In UI, we begin to hit the Pareto principle http://en.wikipedia.org/wiki/Pareto_principle >>> This is a good and a bad news. It means we achieved most and to >>> achieve the rest it will cost us (actually in our case, I'm much >>> more confident because we actually hitted Pareto wall earlier :o) >> >> [citation needed] > > :D > > I just meaned that we are above 80% of UI accomplishment and that > future percentages will cost more and more (for less and less > benefits)... As simple as Jungle Rule... On one hand I'm pessimistic: I wish it were so and I really think we have a long way to go with the OFBiz UI, especially since pretty things and header improvements and such help (and there is still much room for improvement there), but only have a small effect on usability. I like to this of usability using the common legal term of "fitness for a purpose", and that implies that a well defined purpose is in place and is the basis for design so that users can easily perform common tasks. That requires a lot of specific design as opposed to generic design in OFBiz. The goal of OFBiz as I've stated a few times is to be a good basis and provide tools and generic functionality that make is easy to create this sort of specific functionality for a given intended use. We are started to approach some of this with the specialpurpose apps and with the Requirements and Designs space on docs.ofbiz.org, but ultimately we can't predict even the majority of what most organizations want when you get to a level of detail sufficient to create software that really matches an organization's needs. When you really design from scratch and implement to it (using common tools, processes, structures, etc) then things really vary a LOT between even pretty similar organizations and the flexibility to support that is what we're all about. On the other hand I'm optimistic: at least we're not close to the 20% of work that makes 80% of the difference. Or are we? Maybe what I described above about apps design to support specific activities that means we have the 20% generic stuff that makes 80% of the different by reuse in more specific apps, and not we are getting to the hard part of the 80% that makes up the last 20% of what users need, and that is unfortunately usually best done custom because that last part is so hard to predict and is so different in different types of companies, and even of different companies of the same type. A little pontificating is always fun... ;) -David |
|
Administrator
|
From: "David E Jones" <[hidden email]>
To: <[hidden email]> Sent: Tuesday, February 03, 2009 8:12 PM Subject: Re: Some i18n issues > > On Feb 3, 2009, at 11:04 AM, Jacques Le Roux wrote: > >> From: "Adrian Crum" <[hidden email]> >>> Jacques Le Roux wrote: >>>> In UI, we begin to hit the Pareto principle http://en.wikipedia.org/wiki/Pareto_principle >>>> This is a good and a bad news. It means we achieved most and to >>>> achieve the rest it will cost us (actually in our case, I'm much >>>> more confident because we actually hitted Pareto wall earlier :o) >>> >>> [citation needed] >> >> :D >> >> I just meaned that we are above 80% of UI accomplishment and that >> future percentages will cost more and more (for less and less >> benefits)... As simple as Jungle Rule... > > On one hand I'm pessimistic: I wish it were so and I really think we > have a long way to go with the OFBiz UI, especially since pretty > things and header improvements and such help (and there is still much > room for improvement there), but only have a small effect on > usability. I like to this of usability using the common legal term of > "fitness for a purpose", and that implies that a well defined purpose > is in place and is the basis for design so that users can easily > perform common tasks. That requires a lot of specific design as > opposed to generic design in OFBiz. The goal of OFBiz as I've stated a > few times is to be a good basis and provide tools and generic > functionality that make is easy to create this sort of specific > functionality for a given intended use. We are started to approach > some of this with the specialpurpose apps and with the Requirements > and Designs space on docs.ofbiz.org, but ultimately we can't predict > even the majority of what most organizations want when you get to a > level of detail sufficient to create software that really matches an > organization's needs. When you really design from scratch and > implement to it (using common tools, processes, structures, etc) then > things really vary a LOT between even pretty similar organizations and > the flexibility to support that is what we're all about. > > On the other hand I'm optimistic: at least we're not close to the 20% > of work that makes 80% of the difference. Or are we? Maybe what I > described above about apps design to support specific activities that > means we have the 20% generic stuff that makes 80% of the different by > reuse in more specific apps, and not we are getting to the hard part > of the 80% that makes up the last 20% of what users need, and that is > unfortunately usually best done custom because that last part is so > hard to predict and is so different in different types of companies, > and even of different companies of the same type. > > A little pontificating is always fun... ;) I love pontificate :D (anyone lurking this ML knows that already) Jacques > -David > |
«
Return to OFBiz - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |