Adrian I think we are almost on the same page, please read inline. 2011/1/30 Adrian Crum <adrian.c...@sandglass-software.com>
> The application developer designs the application, not the graphic artist. > The graphic artist styles the application, he doesn't design it. > 100% agreed > > For example, I am a developer designing a screen. The screen requires two > sets of links. The links in set A all share something in common, and the > links in set B all share something in common, but sets A and B have nothing > in common. How do I indicate that to the user? I will use different styles > for the two sets of links. > IMO when a developer in this situation he should think: "What is the functions of the links in set A and i set B?. Are they similar or equivalent to functions that already exist in the rest of the applications?" For the set where the answer is yes than the link style should be the one used for that function in the other application. For the set where the answer is no than a new style should be defined with a name that describes the new function. > What you're saying is that I am not allowed to make that decision - that is > the theme designer's decision. I don't agree with that view. The theme > designer is free to style set A and set B any way they want, but it is not > their job to determine if set A or set B exist in the application. > As explained above the developer is absolutely free to define new functional styles but FUNCTIONAL because, as you say, he is responsible for functions offered to the user, not of how they appear. So, for example, he is allowed to style a submit button with a "confirm" or a "cancel" style but he should never be allowed to attach a "smallSubmit" or a "largeSubmit" style to it. If the confirm buttons should appear smaller or greater than the cansel buttons is something that the graphic artist should decide. > As an application developer, I want the option to use different styles to > provide different visual cues to the user. > You will have this option as explained. The graphic artist will help you to have it consistent in all the applications. > > I agree that some of the styles have been named poorly. We should rename > them if that is the case, but we shouldn't get rid of them. > The process can be gradual. I am trying to have a common agreement first so that we will not fight for every style changed or removed. So moving on, we should agree on the rationale behind it than make a list of styles to be removed or changed toghether with new functional names to be used all over the application and then gradually proceed in inplementing. Thank you for you help on this. -Bruno > -Adrian > > > On 1/29/2011 2:35 PM, Bruno Busco wrote: > >> Adrian, >> I am sorry to put again this on the table. I know we have already >> discussed >> about but I think that you are trying to better explain over and over a >> wrong concept. >> You can see how it is wrong when you say "In the original visual theme, >> the >> tab-bar decorator was used for the sub-menu at the top of the main content >> area, button-style-1 was used for intra-app links, and button-style-2 was >> used for inter-app links." >> >> It cannot be a visual theme to use a decorator for a sub-menu, >> button-style-1 for intra-app links etc. It is the application itself. So >> why >> the application should decide which style should be used for a sub-menu? >> It >> should only identify the sub-menu as a sub-menu and then the visual theme >> should decide to decorate the sub-menu with a specific visual aspect. >> >> If the application developer A is free to use button-style-1 for intra-app >> links and button-style-2 for inter-app links then application developer B >> would be free to use button-style-1, let me say, for backoffice links and >> button-style-2 for ecommerce web site links. >> >> Then how could a visual theme designer create a graphics that somehow >> helps >> the user to distinguish between links? >> He could not do anything, he will understand that if the two decoration >> classes have not the same CSS the links will appear different without a >> clear reason and so we will have that the two classes will be, in a proper >> designed theme, with the same CSS. >> >> We are moving now towards having more visual themes hosted separately from >> the main trunk. If we do not clear away those ambiguity we will never have >> a >> solid base in the main trunk to let external visual themes to rely on. >> >> So my suggestion is to change all style names that do not describe element >> functionality but visual aspect. >> Of course I get your suggestion to spend some time removing box* styles >> but >> they should not be the only one to leave. >> >> -Bruno >> >> >> 2011/1/29 Adrian Crum<adrian.c...@sandglass-software.com> >> >> I'm sure we discussed this just a few weeks ago, but I will go over it >>> again... >>> >>> The button-style-1 and button-style-2 CSS classes are button-bar class >>> decorators. The button-bar class has other decorators too - tab-bar and >>> tool-bar. Altogether, there are four button-bar decorators. The >>> button-bar >>> decorators were not intended to be used alone to style links, but they >>> have >>> been used that way recently and I have been fixing those instances as I >>> come >>> across them. >>> >>> Setting up the CSS classes this way gives the graphic artist some >>> flexibility in styling the buttons. Attributes that all button bars have >>> in >>> common (spacing, positioning, orientation) can be applied to the >>> button-bar >>> class, and then the various decorators can have attributes that make them >>> unique. >>> >>> It is up to the application developer to decide what the various >>> button-bar >>> decorators represent. The decorators have no inherent purpose - they >>> simply >>> provide the developer with some choices. In the original visual theme, >>> the >>> tab-bar decorator was used for the sub-menu at the top of the main >>> content >>> area, button-style-1 was used for intra-app links, and button-style-2 was >>> used for inter-app links. >>> >>> I see no reason to remove any of the button-bar decorators. The >>> decorators >>> give the developer and graphic artist a palette of choices. That same >>> concept gives us a choice of table header styles, table grid styles, etc. >>> >>> If there is an interest in removing unnecessary styles, then (in my >>> opinion) that effort should be invested in removing the deprecated CSS >>> styles. You can find them listed at the bottom of the Flat Grey >>> maincss.css >>> file. Removing the box* styles would be a good place to start. >>> >>> -Adrian >>> >>> >>> On 1/29/2011 6:46 AM, Bruno Busco wrote: >>> >>> Hi, >>>> again on this topic. >>>> >>>> I have seen that in the new Flat grey theme the button-style-1 and >>>> button-style-2 are rendered in the same way. >>>> I agree on this and was going to do the same on the Tomahawk theme. >>>> While doing this I asked myself if it does make sense to keep those two >>>> styles. >>>> >>>> They seems to be intended to be used to differentiate between intra-app >>>> and >>>> inter-app links. >>>> But why an user should be aware of the matter that a link is an >>>> intra-app >>>> or >>>> inter-app ? >>>> Shouldn't it be completely transparent to him? >>>> >>>> I think that keeping these styles is only confusing and I would like to >>>> remove it. >>>> Moreover we should go toward style names that describe element functions >>>> and >>>> not their apparence. >>>> For example the "create", "delete", "search", "refresh" button styles >>>> have >>>> not been defined as "button-with-plus", "button-with-cross", >>>> "button-with-maglens" etc. >>>> >>>> The new Demo page layout is a great tool to test themes. >>>> It could also work as a "style dictionary" having all allowed styles >>>> present >>>> on the page and specifiyng that only styles present in this page should >>>> be >>>> used in the rest of the code. >>>> >>>> Does anybody see any issue if we get rid of the button-style-1 and >>>> button-style-2 styles? >>>> >>>> Thank you, >>>> Bruno >>>> >>>> >>>>
