Going on a Safari....

Allison Bloodworth abloodworth at berkeley.edu
Fri Jan 9 20:27:02 UTC 2009


I would say that it depends on how far off the font size of the button  
is from the desired font size. If the user is in an application where  
they've been using buttons that all look like the native controls,  
when they see a differently styled button they may have to stop and  
think about whether it works differently than the other buttons, and  
whether it will actually do what they want it to do. Or worse yet,  
they may not even realize it's a button.

If the font size is only slightly different than the other font sizes,  
I'd say it's more important that it looks like a button. If it's way  
off and the user may have trouble reading or seeing the button, then  
font size is more important.

Cheers,
Allison

On Jan 9, 2009, at 9:02 AM, Jacob Farber wrote:

> Please see the attached files on this JIRA ticket for more info:
>
> http://issues.fluidproject.org/browse/FLUID-1986
>
>
>
>
> On Fri, Jan 9, 2009 at 11:43 AM, Jacob Farber <jacob.farber.work at gmail.com 
> > wrote:
> I didnt send these to the list the first time....
>
>
> ---------- Forwarded message ----------
> From: Jacob Farber <jacob.farber.work at gmail.com>
> Date: Fri, Jan 9, 2009 at 11:03 AM
> Subject: Re: Going on a Safari....
> To: Justin <justin.obara at utoronto.ca>
>
>
> With the attached images you can see the fundamental differences.  
> Please bear in mind this is a bare bones approach with no effort to  
> make the basic button more attractive.
>
> Jacob
>
>
> On Fri, Jan 9, 2009 at 10:56 AM, Jacob Farber <jacob.farber.work at gmail.com 
> > wrote:
> +1 for documenting all these discrepencies in one place.
>
> The FSS CSS would normalize the appearance of the button everywhere  
> in thedocument, not just UI Options..
>
> Im prepping screenshots right now....
>
>
> On Fri, Jan 9, 2009 at 10:39 AM, Justin <justin.obara at utoronto.ca>  
> wrote:
> In general I would agree that the font size would out weigh the  
> merits of the native appearance of the button. However, I have a  
> question.
>
> I'm assuming that this solution would only solve the problem for the  
> button in the component, and that the other buttons the integrator  
> puts on the page would still suffer from this issue.
>
> In that case, would it be confusing to the integrator why it works  
> in some places and not in others? If this is a problem with the  
> browser, it may be a good idea to document the issue.
>
> In general, it may be helpful to have a section on the wiki or build  
> site that demonstrates all of  the 3rd party issues that we have  
> encountered and are reliant on someone else to fix. (i.e. browser  
> specific issues that don't have a work around) This would also  
> provide us with a point of reference to determine if new browser  
> versions solve these issues.
>
> Justin
>
> On 9-Jan-09, at 9:41 AM, Anastasia Cheetham wrote:
>
>
> On 8-Jan-09, at 4:35 PM, Jacob Farber wrote:
>
> Do you think it's acceptable to squash the native appearance of a  
> form control in order to force it to accomodate other settings? Is  
> it more user-friendly for the font size to render properly or for  
> the form control to look like a native control?
>
> Hm... This is an interesting question.
>
> First, I think a screen shot or two might help convey just what the  
> button looks like when you do and don't do your proposed solution.
>
> My reaction is: I would think it would be better to sacrifice the  
> native appearance in favor of a 'properly functioning' button.
>
> -- 
> Anastasia Cheetham                   a.cheetham at utoronto.ca
> Software Designer, Fluid Project    http://fluidproject.org
> Adaptive Technology Resource Centre / University of Toronto
>
> _______________________________________________________
> fluid-work mailing list - fluid-work at fluidproject.org
> To unsubscribe, change settings or access archives,
> see http://fluidproject.org/mailman/listinfo/fluid-work
>
>
>
>
>
> _______________________________________________________
> fluid-work mailing list - fluid-work at fluidproject.org
> To unsubscribe, change settings or access archives,
> see http://fluidproject.org/mailman/listinfo/fluid-work

Allison Bloodworth
Senior User Interaction Designer
Educational Technology Services
University of California, Berkeley
(415) 377-8243
abloodworth at berkeley.edu




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://fluidproject.org/pipermail/fluid-work/attachments/20090109/fc21e410/attachment.html>


More information about the fluid-work mailing list