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