hi bill
i'm sorry if i sounded harsh on this issue in my previous
mail, its just that when so many changes happens at once on
something we have seen working (more or less) for a good
while i get paranoid :)
Bill Moseley wrote:
>
> At 01:43 PM 04/18/02 +0800, allan wrote:
> >a) the prev|up|next navigation sits bad IMO on the left side
> >in the sense i read from left to right. a user will normally
> >go forward i reckon.
>
> But it puts [prev] to the far left, so when you read backwards it's the
> correct flow.
well yes ;)
but one of the very nice things about the righthand-side of
the prev|up|next was that you just kept the mouse pointer in
the same positioned and "scrolled" with a click to the next page.
this is still valid with your soloution of course, but to me
it just doesn't feel "natural" to navigate from the left or
rather about 200px from the left, i simply just prefer the
fixed righthand side. personal taste.
> The point was if there's both the search box and the navigation on the top
> of the page it looks worse with search on the left and nav right.
and that point i actually like:)
[there's no way i could survive the search at the nav left :)]
> >a2) if we stick to this we need to fix the bottom as well
>
> Fix what? So they line up?
yes!
> Again, the words flow off the right, so
> navigation follows there. I don't think it's a problem that they don't
> align vertically.
>
> <<prev
> ssl;fjsd l;ksjf lkjls fl;fjslkfldsj
> sa;jkfslj sdlfjlskd jfsda;lfj sdlk
> alkj lsajflk jjsddjs;fkls lfjds sdl
> next >>
>
did you in fact mean?:
<<prev|up|next
ssl;fjsd l;ksjf lkjls fl;fjslkfldsj
sa;jkfslj sdlfjlskd jfsda;lfj sdlk
alkj lsajflk jjsddjs;fkls lfjds sdl
prev|up|next >>
personally i dont find it such a big issue, though a slighly
confusing, but if we send it to the user-friendly-police i
think people will prefer similar navigation to be placed similary.
> >b) introduing a submit button as image will, as we have
> >seen, cause problems at least in one particular browser
>
> bumby:/home/moseley# apt-get install one-particular-browser
> Reading Package Lists... Done
> Building Dependency Tree... Done
> E: Couldn't find package one-particular-browser
>
> Can you provide more details?
dial 999
ask for netscape-surgey dept, room 4*
> The styles were used to fix one particular browser. NS4
>
> >d) there was a reason we removed the seacrh from the topbar
> >a couple of weeks ago
>
> I know. I can't remember it either.
>
> I think it was because it looked ugly on the left side of the top bar, the
> form button was ugly and rendered differently in different browsers, and
> the input field was huge on Netscape without using styles on the input form
> element.
right, and your soloution does actually renders nicely in
ns4. however see below, html-checking
> Here's a few variations on the theme of the search box on the right side.
>
> http://www.php.net/
> http://aspn.activestate.com/ASPN/Downloads/ActivePerl
> http://perl.com/
> http://java.sun.com/
> http://www.ibm.com/ (not that close)
>
> A few of those I looked at used different style sheets for NS4. Most I
> looked at used styles for the form elements.
well the search-bar look crappy at perl.com in ns4, i guess
they dont care.
the others, have you checked valid html?
> >i do like that the search at the top, but i prefer a decent
> >looking search in the leftbar (which is also very common)
> >instead of this solution at the top. i think the recent topbar
> >was way more "sharp", talking from the camel to the
> >titlebar. if you take a look at the recent versions you will
> >not notice that you are seeing "html", whereas the minute
> >you introduce form elements right in your face it _looks_ ugly.
>
> I agree. See that was my thinking about the navigation widgets with the
> line around them and some (Up, SRC) reverse. The look like form elements,
> and too top heavy and detracted from the content. Obviously, that's opinion.
>
> And is why I suggested the look of
>
> http://mardy.hank.org:5000/test1/download/index.html
>
> It's not like people can't find the navigation in that example. It's just
> different.
true.
> We are all going to have personal opinions, and favor things we worked on.
> I like more white space, simple, plain text instead of buttons (e.g. simple
> prev text instead of [prev] button). But someone has to make a decision.
> I don't really care which way.
+1
i couldnt really agree more. well put.
> Stas feels, I believe that the search box on the side-bar took up too much
> space (I agree -- and maybe you can come up with something better). Stas
> also said that it makes more sense logically for the search to be with the
> content (I don't really belive this, really, as I don't think the vast
> majority of people see the page quite the same way we do -- they just see a
> page that's designed like the other pages in the site). People are going
> to get confused. I do think the site could use a tiny bit more color,
> which is something people will see. Don't want people to think mod_perl is
> dull ;)
>
> >> - I'm using px settings for the input and select styles. Might need to fix
> >> that.
> >
> >-1 for any styles on any form element - you are introducing
> >more problems i think
>
> I have three browses running on Windows and three on Linux (well
> Galeon/mozilla are almost the same). What browser do I need to install
> that will show me the problems?
[call 999]
as far as i recall you had problems yourself with the search
(in the leftbar) that was to wide or something. when we
removed the styles that got solved. i also saw problems
myself with that styled-search box in netscape 6.2 and
generallt opera5+, ns6 and ie5+ has on my platform very
different rendering of styles in form elements.
cheers
./allan
> --
> Bill Moseley
> mailto:[EMAIL PROTECTED]
---
Line 205: Attribute �nowrap� for element �<td>� must be
empty; value was specified as �nowrap�.
Line 208: Document type doesn't permit empty XML element; �<input/>�.
Line 208: Document type doesn't permit attribute �width�
within element �<input>�.
Line 208: Document type doesn't permit attribute �height�
within element �<input>�.
Line 208: Document type doesn't permit attribute �border�
within element �<input>�.
Line 208: Document type doesn't permit attribute �hspace�
within element �<input>�.
Line 530: Attribute �nowrap� for element �<td>� must be
empty; value was specified as �nowrap�.
Line 530: Document type doesn't permit empty XML element; �<input/>�.
Line 530: Document type doesn't permit attribute �width�
within element �<input>�.
Line 530: Document type doesn't permit attribute �height�
within element �<input>�.
Line 530: Document type doesn't permit attribute �border�
within element �<input>�.
Line 530: Document type doesn't permit attribute �hspace�
within element �<input>�.
___
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
