You are viewing a plain text version of this content. The canonical link for it is here.
Posted to docs-dev@perl.apache.org by allan <la...@inet.uni2.dk> on 2002/03/06 05:43:40 UTC
search_look ... again
hi
i have enclosed a gif which was done in html.
the shot is from ie5.1 mac and looks really good in ns4 and
opera* (havent checked ns6 but im pretty sure it looks ok)
* actually it seems opera has a fixed height for text-fields
so maybe all the widgets should have their height increased
to about 22px instead of 20px, but i didn't want to go there
before sending this mail.
comments:
- there is no submit button i know. the reason is that it
would look bad inside the widget. besides theres no need for
one. anyone who cannot find out to search the site will
click on the menuitem help and learn how to press enter.
- there is no input type="image" because i _know_ (i
think:)) that this will never _look_ good in a certain
browser causing us many problems. besides there were some
problems when hitting the enter-key.
- there is also no js-focus(). i simply dont believe in it
for our design. i think we are wasting our time on this.
so basically i think this is the best compromise of all
worlds. it works across browsers, it fits our design across
browsers. it makes the "toolbar" consistent.
./allan
RE: search_look ... again
Posted by "Jonathan M. Hollin" <ne...@digital-word.com>.
:: Does anybody know, which browsers don't support the
:: enter-as-submit when using an image as a submit button?
As far as I can tell NS6 on Win32 doesn't;
IE6 (Win32) does.
To my mind it doesn't matter. If your browser supports enter->submit
then great, but if not, then you have a button to click (which is
standard and expected behaviour anyway) - no functionality is lost for
anyone.
You all already know that I am -1 on no button. For the record, I am
indifferent (+0) as to whether that button is HTML or an image. I don't
think useability suffers either way as most users are familiar with
both. In which case, perhaps we can opt for cosmetics and use an image?
Jonathan M. Hollin - WYPUG Co-ordinator
West Yorkshire Perl User Group
http://wypug.pm.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
Re: search_look ... again
Posted by Thomas Klausner <do...@zsi.at>.
Hi!
On Wed, Mar 06, 2002 at 03:15:12PM +0800, Stas Bekman wrote:
> > true, but were do we make the cut, userbility vs looks vs
> > errors vs ns4 ...?
> I don't know. me trying to keep everybody happy ;)
1: Usability
2: Looks
...
99: NS4 :-)
> >>-1: Bill, Jonathan, Thomas
> > stas im trying to s/-1/+1/g;
Does anybody know, which browsers don't support the enter-as-submit when
using an image as a submit button?
Because IMO the best solution would be to use an image (looks nice and is
userfriendly) /if/ nearly all browsers support enter-as-submit.
If there are a lot browser that cannot do that, I would definitly use
standard submit button, because having just an imput field without anything
to click on is IMO to confusing. (BTW, I don't know how text-only browsers
would handle a form without a submit (just tested with lynx, which can
handle it))
> > i think i prefer them as text/fonts, not images. im not sure
> > though what is best
As images and text cannot be mixed without beeing noticed (even if it looks
OK on all tested browser, user still can change their default font size,
thus breaking the design), I'm
+1 on plain text
--
D_OMM +----> http://domm.zsi.at <-----+
O_xyderkes | neu: Arbeitsplatz |
M_echanen | http://domm.zsi.at/d/d162.html |
M_asteuei +--------------------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
Re: search_look ... again
Posted by Stas Bekman <st...@stason.org>.
allan wrote:
> Stas Bekman wrote:
>
>>but most of the folks who responded, were -1 on not having the submit
>>button.
>>
>
>>I definitely agree with you that your snapshot looks great! But we don't
>>want usability to suffer.
>>
>
> true, but were do we make the cut, userbility vs looks vs
> errors vs ns4 ...?
I don't know. me trying to keep everybody happy ;)
>>If I'm not mistaken currently we have:
>>
>>-1: Bill, Jonathan, Thomas
>>-0: Stas
>>+1: Allan
>>
>>for not having the submit button.
>>
>
> stas im trying to s/-1/+1/g;
good luck ;) I'm neutral here
>>my only question is whether we should turn pdf and src labels into
>>images to make sure that the same text font/size is used as in prev|next
>>or simply to use text. mainly because the sizes cannot be part of the
>>image, so it's good to have the size and the label (pfd|src) of the same
>>typeset.
>>
>
> i think i prefer them as text/fonts, not images. im not sure
> though what is best
anybody thinks images would be better?
Allan, in the meantime, can you please send me the patch for the
text/fonts as you've done in your snapshot? only download template this
time. Thanks.
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:stas@stason.org http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
Re: search_look ... again
Posted by allan <la...@inet.uni2.dk>.
Stas Bekman wrote:
> but most of the folks who responded, were -1 on not having the submit
> button.
> I definitely agree with you that your snapshot looks great! But we don't
> want usability to suffer.
true, but were do we make the cut, userbility vs looks vs
errors vs ns4 ...?
> If I'm not mistaken currently we have:
>
> -1: Bill, Jonathan, Thomas
> -0: Stas
> +1: Allan
>
> for not having the submit button.
stas im trying to s/-1/+1/g;
IMO a submit button = search widget a different place on the
pages, and that widget should be preferably plain old html (poh).
hey, that would maybe be a good idea also for the focus
function ?
> my only question is whether we should turn pdf and src labels into
> images to make sure that the same text font/size is used as in prev|next
> or simply to use text. mainly because the sizes cannot be part of the
> image, so it's good to have the size and the label (pfd|src) of the same
> typeset.
i think i prefer them as text/fonts, not images. im not sure
though what is best
./allan
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
Re: search_look ... again
Posted by Stas Bekman <st...@stason.org>.
allan wrote:
> hi
>
> i have enclosed a gif which was done in html.
> the shot is from ie5.1 mac and looks really good in ns4 and
> opera* (havent checked ns6 but im pretty sure it looks ok)
>
> * actually it seems opera has a fixed height for text-fields
> so maybe all the widgets should have their height increased
> to about 22px instead of 20px, but i didn't want to go there
> before sending this mail.
>
>
> comments:
>
> - there is no submit button i know. the reason is that it
> would look bad inside the widget. besides theres no need for
> one. anyone who cannot find out to search the site will
> click on the menuitem help and learn how to press enter.
but most of the folks who responded, were -1 on not having the submit
button.
I definitely agree with you that your snapshot looks great! But we don't
want usability to suffer.
If I'm not mistaken currently we have:
-1: Bill, Jonathan, Thomas
-0: Stas
+1: Allan
for not having the submit button.
> - there is no input type="image" because i _know_ (i
> think:)) that this will never _look_ good in a certain
> browser causing us many problems. besides there were some
> problems when hitting the enter-key.
+1
> - there is also no js-focus(). i simply dont believe in it
> for our design. i think we are wasting our time on this.
+1
> so basically i think this is the best compromise of all
> worlds. it works across browsers, it fits our design across
> browsers. it makes the "toolbar" consistent.
my only question is whether we should turn pdf and src labels into
images to make sure that the same text font/size is used as in prev|next
or simply to use text. mainly because the sizes cannot be part of the
image, so it's good to have the size and the label (pfd|src) of the same
typeset.
--
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:stas@stason.org http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
Re: search_look ... again
Posted by Bill Moseley <mo...@hank.org>.
At 11:33 AM 03/07/02 +0800, Stas Bekman wrote:
> From looking at the source, you've lost 3 hidden input vars.
Yes, I don't think they are needed. You will need to add one back to limit
searches to a section of tree, though.
--
Bill Moseley
mailto:moseley@hank.org
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
Re: search_look ... again
Posted by Stas Bekman <st...@stason.org>.
Bill Moseley wrote:
> At 09:55 PM 03/06/02 +0800, allan wrote:
>
> Stas just mentioned about using pure-text for widgets. This is fine, but
> we would want everything to match up, right? That is prev|up|next as text,
> too.
>
> Frankly, I think graphics are our best bet for consistent design, but
> someone running at 140dpi will complain (duh, of course it looks small).
> If it was me, I'd probably wrap the entire widget row in a table to keep
> them all aligned, but maybe that's not necessary.
Yes, we will go with images. And no 140dpi shouldn't be a problem, since
you should figure out once what the functionality of these images. after
that they can be blank and you will still know what they do ;)
> BTW - Stas, why were the hidden fields in a different template -- which
> required placing the </form> tag there, too? I moved everything into the
> "search" template and it seems to work fine.
>
> For fun, I just used a very simple "search" template and generated this:
>
> http://hank.org:5000/about/about.html
From looking at the source, you've lost 3 hidden input vars. Anyway
I'll try moving these again.
> Now, if you use IE5.5 or IE6.0 you can see the thin border I was talking
> about with
>
> http://hank.org:5000/about/about2.html
>
> Which ends up a lot like the prev|up|next widgets (although I used a
> different font for the "search" button. But, it's hacked up to work in IE
> (just as an example!).
>
> Of course, it doesn't work as well in other browsers, as very few seem to
> apply the style to the input field. Opera applies it, but differently.
> Most seem to make the input box *larger*, so maybe that's my misuse of the
> style tag. What happens is that the input box and submit button are out of
> proportion.
>
> The current CVS solves that by wrapping the input field and search button
> in a table with the dark border, but then although the input field/submit
> button makes a more unified "search" widget, it doesn't match as well with
> the other widgets on that same line as the large input field.
>
> And that style on the input field totally trashes NS4 for some reason. Not
> sure if there's a work-around other than @import.
;(
>>>Is "certain browser" NS4? Technically we can use an image as a button as a
>>>submit, but are you saying you can't create the exact same look and have it
>>>work?
>>>
>>for NS4 not possible _lookwise_. ns4 thinks the image is a
>>link and then puts an unremovable (if we want legal html)
>>border around the image.
>>
>
> Actually, the blue border doesn't look that bad in NS4 (and NS6).
>
> http://hank.org:5000/about/about3.html
>
> Now, the oversized text input field is another story, not to mention the
> resizing problem. So the blue border would be down the list of NS bummers.
> From talking to people the oversized input field is just life.
>
> [out of order quoting]
ok
>>so all in all this solution is only
>>going to look slightly worse in ns4, because of the
>>link-border but will function everywhere one way or the
>>other i guess.
>>
>
> If we use the illegal border="0" I don't think the W3C police will really
> come after us. Will they?
we better not I think.
>>functionality-wise it seems some
>>browsers on some platform doesn't understand the enter-key
>>when this is applied but as jonathan pointed out people will
>>figure out how to click on the image if suddenly their
>>enter-key doesn't work.
>>
>
> I have:
>
> Win98: IE6, Opera6.01, Mozilla0.9.7, NS4.08
> WinME: IE5.5, NS6
> Linux: Mozilla0.9.7 Konquerer2.2.2
>
> All work with the enter key.
good!
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:stas@stason.org http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
Re: search_look ... again
Posted by Bill Moseley <mo...@hank.org>.
At 09:55 PM 03/06/02 +0800, allan wrote:
Stas just mentioned about using pure-text for widgets. This is fine, but
we would want everything to match up, right? That is prev|up|next as text,
too.
Frankly, I think graphics are our best bet for consistent design, but
someone running at 140dpi will complain (duh, of course it looks small).
If it was me, I'd probably wrap the entire widget row in a table to keep
them all aligned, but maybe that's not necessary.
BTW - Stas, why were the hidden fields in a different template -- which
required placing the </form> tag there, too? I moved everything into the
"search" template and it seems to work fine.
For fun, I just used a very simple "search" template and generated this:
http://hank.org:5000/about/about.html
Now, if you use IE5.5 or IE6.0 you can see the thin border I was talking
about with
http://hank.org:5000/about/about2.html
Which ends up a lot like the prev|up|next widgets (although I used a
different font for the "search" button. But, it's hacked up to work in IE
(just as an example!).
Of course, it doesn't work as well in other browsers, as very few seem to
apply the style to the input field. Opera applies it, but differently.
Most seem to make the input box *larger*, so maybe that's my misuse of the
style tag. What happens is that the input box and submit button are out of
proportion.
The current CVS solves that by wrapping the input field and search button
in a table with the dark border, but then although the input field/submit
button makes a more unified "search" widget, it doesn't match as well with
the other widgets on that same line as the large input field.
And that style on the input field totally trashes NS4 for some reason. Not
sure if there's a work-around other than @import.
>> Is "certain browser" NS4? Technically we can use an image as a button as a
>> submit, but are you saying you can't create the exact same look and have it
>> work?
>
>for NS4 not possible _lookwise_. ns4 thinks the image is a
>link and then puts an unremovable (if we want legal html)
>border around the image.
Actually, the blue border doesn't look that bad in NS4 (and NS6).
http://hank.org:5000/about/about3.html
Now, the oversized text input field is another story, not to mention the
resizing problem. So the blue border would be down the list of NS bummers.
From talking to people the oversized input field is just life.
[out of order quoting]
>so all in all this solution is only
>going to look slightly worse in ns4, because of the
>link-border but will function everywhere one way or the
>other i guess.
If we use the illegal border="0" I don't think the W3C police will really
come after us. Will they?
>functionality-wise it seems some
>browsers on some platform doesn't understand the enter-key
>when this is applied but as jonathan pointed out people will
>figure out how to click on the image if suddenly their
>enter-key doesn't work.
I have:
Win98: IE6, Opera6.01, Mozilla0.9.7, NS4.08
WinME: IE5.5, NS6
Linux: Mozilla0.9.7 Konquerer2.2.2
All work with the enter key.
It's amazing, all these problems with NS4, but it's my favorite client for
testing dynamically generated sites. IE caches too much, oh, and I can't
stand that it won't take in the Address bar: mardy:5000 -- why do I need
to type http:// -- geeze.
--
Bill Moseley
mailto:moseley@hank.org
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
Re: search_look ... again
Posted by allan <la...@inet.uni2.dk>.
Bill Moseley wrote:
>
> At 12:43 PM 03/06/02 +0800, allan wrote:
> >- there is no submit button i know. the reason is that it
> >would look bad inside the widget. besides theres no need for
> >one. anyone who cannot find out to search the site will
> >click on the menuitem help and learn how to press enter.
>
> I'm not really -1, more like -0.5.
and i'm more like +0.3 :)
> some people will just hit enter and think that's cool
> some people will try to click on the word "search" and think that's lame
> when they see it's not a link (unlike all the other widgets on that line).
good point.
> >- there is no input type="image" because i _know_ (i
> >think:)) that this will never _look_ good in a certain
> >browser causing us many problems. besides there were some
> >problems when hitting the enter-key.
>
> Is "certain browser" NS4? Technically we can use an image as a button as a
> submit, but are you saying you can't create the exact same look and have it
> work?
for NS4 not possible _lookwise_. ns4 thinks the image is a
link and then puts an unremovable (if we want legal html)
border around the image. functionality-wise it seems some
browsers on some platform doesn't understand the enter-key
when this is applied but as jonathan pointed out people will
figure out how to click on the image if suddenly their
enter-key doesn't work. so all in all this solution is only
going to look slightly worse in ns4, because of the
link-border but will function everywhere one way or the
other i guess.
> Again, what about using single pixel border style on the text box so that
> it looks more like the single line around the prev|next widget? Or does
> that break in NS4, too?
you cant apply styles to input-fields in ns4 (AFAIK) but it
wouldnt break anything i guess.
if you imagine the text "search" as a submit button in the
screenshot i sent earlier i think we can achieve that kind
of search-widget in all "our" browsers, some slightly better
than the other (the button will of course be on the rightside)
./allab
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
Re: search_look ... again
Posted by Bill Moseley <mo...@hank.org>.
At 12:43 PM 03/06/02 +0800, allan wrote:
>- there is no submit button i know. the reason is that it
>would look bad inside the widget. besides theres no need for
>one. anyone who cannot find out to search the site will
>click on the menuitem help and learn how to press enter.
I'm not really -1, more like -0.5.
some people will just hit enter and think that's cool
some people will try to click on the word "search" and think that's lame
when they see it's not a link (unlike all the other widgets on that line).
The fact is that the text "search" looks like the other widgets so it's
natural to want to click on it. You wouldn't take a screen capture of a
real form submit button, and then use it on a page as plain text -- people
would try to click it.
Again, -0.5 as people will click once or twice and figure it out. Not
worth thinking about too much. People will figure it out, and if not we
can tweak later.
Personally, I think those widgets are a rather prominent design feature of
the site, and thus it might be good to use images for all to maintain
tighter control on the design in all browsers. But if you feel confident
that they will work fine as text, then ok. Download time and text-browsers
are not a good reason against them, though, if that's the reason.
>- there is no input type="image" because i _know_ (i
>think:)) that this will never _look_ good in a certain
>browser causing us many problems. besides there were some
>problems when hitting the enter-key.
Is "certain browser" NS4? Technically we can use an image as a button as a
submit, but are you saying you can't create the exact same look and have it
work? That is, you can't wrap both the input field and the button in a
table (or whatever) to make it look like a single widget (like the other
widgets)?
>- there is also no js-focus(). i simply dont believe in it
>for our design. i think we are wasting our time on this.
I'll agree it's not worth our time. If you don't believe in it for
technical reasons, I'll go along with that, too.
Again, what about using single pixel border style on the text box so that
it looks more like the single line around the prev|next widget? Or does
that break in NS4, too?
Thanks,
--
Bill Moseley
mailto:moseley@hank.org
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org