Gentoo Archives: www-redesign

From: Aaron Shi <aaron@××××××××.com>
To: www-redesign@l.g.o
Subject: RE: [www-redesign] a couple of comments
Date: Mon, 12 Dec 2005 08:28:49
Message-Id: 003301c5fef6$d76e7f00$6402a8c0@vega
In Reply to: Re: [www-redesign] a couple of comments by Curtis Napier
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