getting closer. I agree with you both. See comments inline...
Ryan L. Foster
801.671.0769
cont...@ryanlfoster.com
ryanlfoster.com
On Jan 30, 2011, at 1:25 AM, Adrian Crum wrote:
> On 1/29/2011 11:59 PM, Bruno Busco wrote:
>> 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
+ 1. Although I think it would be great if we could get more active UxD and
IxD (User Experience and Interaction Design) participation in the UI as a
whole. An effective interface is SO much more than just making a screen look
nice. An experienced Interaction Designer can offer valuable insight on how
much is too much when it comes to forms and data on a page, how and where to
place a form to make it easier to use, and possibly suggest ways to break up
complex interactions or workflows to make it easier for the end user to use.
If some of these decisions could be made in collaboration at the development
level, it can make the theme designers job a lot easier and improve the UI of
the application as a whole in the long run.
>>
>>
>>> 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.
>>
>
> So, every application that has a group of links that aren't common to other
> applications should have its own style for that set of links? Are you
> serious? Every application would have its own style sheet then. NO NO NO. The
> concept is to have a palette of styles for the application developer to
> choose from, not to have a separate set of styles for each application.
>
> The bottom line is, there is no valid reason to remove the two styles. There
> are valid reasons to rename them. If you are REALLY REALLY REALLY motivated
> to remove styles, then PLEASE PLEASE PLEASE remove the deprecated styles -
> not the ones we're currently using.
>
> -Adrian
Agreed. I think having different grouping options is a good thing. But, lets
add the classNames and IDs to the group, not the buttons or links inside the
group. The designer can easily target styling from there much easier than
having to worry about individual styles for buttons.
(For example #main-nav .btn, #subnav .btn {...} The groups are different, but
the common button elements share the same className).
Start at a granular level and work up from there. First, have all of the
buttons look the same, then have all the links look the same, making sure there
is a distinction between a button and a link. Then you can begin to target
styling for these elements based on grouping.
So in summary: +1 for renaming, +1 for re-labeling, -1 for removing, and ++1
for consolidating. Is that clear enough?
>
