Gentoo Archives: www-redesign

From: Curtis Napier <curtis119@g.o>
To: www-redesign@l.g.o
Subject: Re: [www-redesign] a couple of comments
Date: Mon, 12 Dec 2005 02:35:54
Message-Id: 439CE1FE.20104@gentoo.org
In Reply to: [www-redesign] a couple of comments by Aaron Shi
1 Aaron Shi wrote:
2 > Wow, took a quick peek and everything looks much nicer.
3 >
4 > A couple of things (here it goes):
5 >
6 > --1--
7 >
8 >>When I saw the e-mail icon next to the print icon, my first
9 >>thought was that it was a "send-a-link" button, since that's
10 >>pretty common on news sites. Having it represent a mailto:
11 >>link instead might be potentially confusing. Anybody else think that?
12 >
13 >
14 > It is misleading and counter intuitive. The original reference was for
15 > "send-a-link," but to do that it requires javascript and hence that's
16 > probably why it was changed to a static mailto: link.
17 >
18
19 A little picture of a mail envelope represents a send-a-link? If so many
20 people think so then I'll just remove it. To me it's pretty intuitive
21 that it means "send a mail" and since it's a gentoo page I assume it's
22 sending a mail to someone at gentoo.
23
24 Since the current gentoo website doesn't have that link and since it
25 wasn't Aarons orginal intention for it to be a mailto link *and* because
26 so may people have mentioned it I will just remove it.
27
28 Fixed in CVS.
29
30 > --2--
31 >
32 >>There are a few other minor changes as well. Link colors have
33 >>been made more consistant: purple on white for content areas
34 >>and white on purple in the menu bar. All links turn green on
35 >>:hover. These color combinations pass the color-blind test,
36 >>look really good and are consistant.
37 >
38 >
39 > The green was intended for on the dark purple background on the top bar or
40 > bolded text headings. It is not intended for unbold non-heading text on
41 > white background or on light purple background (especially hard to see, e.g.
42 > hover ad links on the ad bar). Also, the ad images have dotted underlines
43 > under them, they shouldn't.
44 >
45
46
47 I tried to take your repeated advice to be "consistant" and apply it to
48 the links. We have purple on white links, white on purple links. I think
49 we can both agree that is good(?) Having a hover color is important for
50 several reasons. Let me explain the full logic of why I choose the
51 colors for the links, hopefully you will agree.
52
53 1. hover color is the standard for links and the green is one of the
54 official theme colors. Using it for ALL links is "consistant".
55
56 2. we are using dotted underlines instead of solid ones. This confuses a
57 lot of people who think they are <acronym>'s instead of <a href>'s so
58 having a different color on hover is more consistant with a normal <a
59 href>'s behaviour.
60
61 3. the light purple on the dark purple is invisible to color-blind
62 people (this one is very very important)
63
64 4. the inconsistancy of links was the number 1 thing people had negative
65 feedback on. This current link color theme has gotten thumbs up from
66 everyone I have talked to about it. Especially color-blind people. The
67 hover color is a great visual que that it is an <a href> and not an
68 <acronym> since <acronym>'s don't have a hover color by default (the
69 dotted line changing to a solid one helps too but isn't enough).
70
71 The green is the normal green that is used for a lot of little things
72 around the site so I used it since it's "consistant". It looks good on
73 the white and on the purple. I agree it may be a *little* hard to read
74 on the light purple background but it's a hover color and you only see
75 that color if the mouse is over the word anyway. It's kind of hard to
76 read with the mouse covering the word anyhow so what's the difference?
77
78
79 > --3--
80 >
81 >>The top level menu (main, planet, forums, etc...) had an
82 >>issue. The green arrow designates which site you are on. If
83 >>you are on planet.gentoo.org then PLANET would be first in
84 >>line with the green arrow. I spaced the first word out more
85 >>to make it more obvious. The link colors were changed to
86 >>white with green hover to be consistant with the site-wide
87 >>color scheme and also to pass the color blind test.
88 >
89 >
90 > Hmm...we shouldn't changed the menu order on the users. It creates
91 > confusion and slows down the workflow because they'd have to double-check
92 > the position of the links before clicking due to them changing. How about,
93 > current site = white link, other sites = dimmer (i.e. light purple). Also
94 > the green arrow doesn't vertically align with the text as in the reference,
95 > not sure why merely changing colors would also change the positioning. The
96 > font looks a tad different, maybe that's why.
97
98 I agree, we shouldn't change the order of the links. What about if the
99 green arrow simply moves to whatever domain you are on and add a little
100 padding around it to make it stand out without actually changing the
101 location of the menu item? This would be consistant with the idea of
102 "this is where you are" and still satisfy the color-blind problem of the
103 light purple link color.
104
105 When those links were still light purple I had several color-blind
106 people ask me "what is that little green arrow doing floating in the
107 middle of the top bar?" They *literally* could not see the light purple
108 links.
109
110 I don't see an issue with the arrow lining up. It seems to be pretty
111 consistant for me on every browser, except for IE which moves it up 1
112 pixel for some reason I can't seem to figure out.
113
114 It's not that big of a deal and I would say it's an acceptable bug (?)
115
116 >
117 > --4--
118 >
119 >>I like this version much better. It's all coming together, and
120 >>I give my thumbs up for a release of this as soon as the minor
121 >>bugs are worked out. (Not like it matters, but as an average gentoo
122 >>user, I applaud you, and everyone else!)
123 >
124 >
125 >>Yes, let's see this before X-Mas 2005! It would be a nice X-mas
126 >>present to the community!
127 >
128 >
129 > I'd strong advise against releasing an unpolished product and patching up
130 > known-bugs later (i.e. pull a Microsoft). Since this is a major event,
131 > there will undoubtly be additional coverage and it would not look good if we
132 > launched it at sub par quality (Gentoo critics would totally capitalize on
133 > it).
134 >
135
136 I do agree that we shouldn't put up a sub-standard piece of work
137 *however*, if everyone involved is OK with it and has the time why not?
138 I would like to see it by at least the New Year. If that isn't possible
139 then so be it but this project was started over a year and a half ago,
140 is it ever going to end?
141
142 </chomping at the bit> ;-)
143
144 > --5--
145 >
146 >>Chapters are the green and a larger font size and sections
147 >>are dark purple and a little smaller. It looks good at the
148 >>moment and (more or
149 >>less) matches the reference design.
150 >
151 >
152 > Looks good, my only concern with this and the other color changes is where
153 > the colors came from. Are they part of the color scheme? The dark purple
154 > sub headings, while the text is of higher contrast (is it necessary?), it
155 > over shadows the green heading (even though the green heading is larger),
156 > this is because the apparent brightness is inconsistent. The purple in the
157 > reference looks more balanced. The headings (green, purple, and doc heading
158 > at top in the light purple box) could be a little bigger as our default text
159 > is bigger.
160 >
161
162 Sorry, I had the wrong color-code for the purple header. I also
163 increased the font size for the green header to make it more prominent.
164
165
166 > --6--
167 > On the front page, there's a light purple space below between the content
168 > area and the footer bar. To the right of the line where it says "#103610 -
169 > yaboot-static claims incorrectly that /proc/device-tree broken is in the
170 > 2.6.12 kernel series", the ad bar is shifted by 1 pixel to the right (this
171 > is barely noticeable but very odd).
172 >
173
174 I didn't notice the body overflowing under the content area there (I use
175 moz and opera and only test with IE every once in a while). The light
176 purple bar under the content area is an IE only bug and I fixed it.
177
178 Ad bar being shifted by 1 pixel? I don't see that in any of the
179 browsers. Can you take a screenshot?
180
181
182 > --7--
183 > The front page looks over crowded, I think this is mostly a spacing issue
184 > (or lack of). Giving the purple bar headings a padding and putting more
185 > space between each news item may help a little temporarily. The "More News"
186 > link needs to be more prominent, right now it just looks like part of the
187 > last news item.
188 >
189
190 The spacing issue is because you are apparently using IE to view it.
191 Spacing is not an issue on any other browser. I have added a padding to
192 the <td>'s of that table to accomodate IE, this increases the already
193 existing padding on non-IE browsers though and I'm not sure it looks good.
194
195 I increased the padding of the header as you suggested but it looks
196 horrible. The reference design doesn't have a padding either and I like
197 the look of it much better. Look at it now with the increased padding
198 between news items and see what you think. Also try using firefox or
199 opera and see the difference between them and IE.
200
201
202 > --etc.--
203 > The table borders might look better in a purple (right now it appears black
204 > or very dark gray).
205
206 Grey at the moment. Which of the purples? Give me a color code.
207
208 >
209 > The XML buttons have dotted underlines, within a sentence it looks okay, but
210 > on its own it looks strange (the underline sticks right to the bottom of it,
211 > essentially same problem as ad images). This is probably a line height
212 > issue.
213 >
214 > The ad column's purple doesn't quite match the light gray portion on the
215 > footer which connects to it. The purple looks nice too, I can probably
216 > change the footer graphic later to match the purple.
217 >
218
219 We are replacing the normal text-decoration:underline of <a href>'s with
220 a border:dotted. This makes the line become a "border" instead of a
221 normal "text-decoration" and so the border is "below" the text line
222 instead of "part of" the text line. I had to increase the line height
223 for the entire content area to 1.3em to make the spacing consistant with
224 what a text-decoration would give us and to remove the overlapping of
225 the border with the line below it.
226
227 It's easy to get rid of the text-decoration on images that are a link
228 with a simple "a img {text-decoration:none}" but it is more complicated
229 to get rid of a border on an <a href> that contains an img. I would have
230 to add a new class to the css and a filter in the xsl that would tag
231 every image with that class in order to get rid of the border. This is
232 overly complicated to do. If anyone knows of a simple way to do it that
233 doesn't involve adding a new class to every single image contained
234 within an <a href> let me know.
235
236 Instead I added vertical-align:text-bottom to "a img" in the css. This
237 doesn't get rid of the dotted border but it does move the border right
238 up to the edge of the image. This isn't a perfect fix but it's better
239 than nothing. What does everyone think of the way it looks now?
240
241
242 >
243 >
244 > Overall good work Curtis, this is coming together nicely! The progress has
245 > been huge in the last couple of weeks.
246 >
247
248 Thanks! :-)
249
250 --
251 www-redesign@g.o mailing list

Replies

Subject Author
[www-redesign] headers, lists and more news Curtis Napier <curtis119@g.o>
RE: [www-redesign] a couple of comments Aaron Shi <aaron@××××××××.com>