1 |
> I should have said that the last update was not complete as |
2 |
> far as design was concerned. I was mainly looking for |
3 |
> accessibility and rendering issues on as many browsers/OS's |
4 |
> as possible. I got that feedback and fixed the issues that |
5 |
> came up. I also implemented the rest of the design so it |
6 |
> should now be more visually appealing and better match Aarons |
7 |
> reference design. I took into consideration all of the |
8 |
> suggestions that were submitted and now ask for additional |
9 |
> feedback to ensure that my changes didn't introduce any |
10 |
> additional rendering/accessibility bugs and that the design |
11 |
> is acceptable to as many people as possible. |
12 |
> |
13 |
> If there are no more outstanding issues reported I will |
14 |
> submit this current layout for approval. |
15 |
|
16 |
Sorry, but this looks worse. The colors (other than what's in the original |
17 |
graphics) are way off. I'm going make a wild guess that an uncalibrated LCD |
18 |
is being used to view the site. Many panels are not capable of the full |
19 |
16.7 million range and uses dithering techniques to emulate the other |
20 |
colors. So in reality, the colors when viewed on proper LCD and CRTs are |
21 |
slightly off (but all the "off-ness" in colors adds up and the combined |
22 |
effect is quite obvious). |
23 |
|
24 |
|
25 |
> Any issues with the |
26 |
> infinity symbol should have been addressed a year ago. |
27 |
|
28 |
Amen. |
29 |
|
30 |
|
31 |
> Aarons reference design at www.aaronshi.com/gentoo/ is |
32 |
> exactly that: A |
33 |
> reference. In it's current form it differs from his original |
34 |
> submission |
35 |
> which was the winning entry and should not be considered as anything |
36 |
> else but a reference. I tried to stick to that design as much as |
37 |
> possible but some things were simply not possible. |
38 |
|
39 |
The reference I made, after listening to comments on the forums, etc., is |
40 |
what I believe an improvement to the original submission. However, the live |
41 |
site right now, while the backend is perhaps implemented with improvements, |
42 |
the frontend (the design) is a deterioration. I understand there are |
43 |
technical limitations to what's possible. I've worked with CMS's and |
44 |
combining backend with frontend etc., but it's about injecting data into the |
45 |
design; not the other way around. This is usually done after reference |
46 |
templates are done and "locked," and the final output of the injection |
47 |
effort is usually very close to the references templates. The Gentoo |
48 |
templating system seems to be such a way that everyone working on this |
49 |
project, Curtis and myself included, have to work contrary to normal |
50 |
processes in order to force things to work. |
51 |
|
52 |
|
53 |
> Aarons design uses a smaller default font, that is not |
54 |
> acceptable from |
55 |
> an accessibility POV. The main font is at 1em and all cursory fonts |
56 |
> multipliers of 1em. The main font will remain at 1em which is the |
57 |
> standard for the accessibility guidelines. If you don't like the |
58 |
> standard font size every single graphical browser offers a font zoom |
59 |
> capability, use it. |
60 |
|
61 |
If you look at all of the professionally designed sites on the Internet, I |
62 |
bet they're using a font size similar to what's in the reference templates. |
63 |
The reality is, most people are _not_ on 1600x1200 resolutions and the font |
64 |
used in the live site is just plain huge. I'm using 1280x1024 and it's |
65 |
still gigantic! (All of my browsers' font zoom is default.) Even |
66 |
mozilla.org's fonts are about half the size of what we're using. Looking at |
67 |
other "modern" open source sites, freebsd (nice facelift), fedora, etc. none |
68 |
of them are using fonts as large as ours, not even close. The browser's |
69 |
zoom capability is really a double-edged sword... |
70 |
|
71 |
That said, all the "reading/content" fonts are controlled using 1 value in |
72 |
global.css, change font-size in body and the whole site will change. The |
73 |
"reading" font I'm referring to is specified for the real substance on the |
74 |
page that people want to read, i.e. the content. The philosophy is that |
75 |
content "reading" fonts can be larger or flexible (hence I put in the |
76 |
font-size adjuster so people can increase/decrease the content font size and |
77 |
have that remembered in a cookie). However, fonts that are an inherent part |
78 |
of design should be congruent with the design itself. |
79 |
|
80 |
E.g. Redhat, http://www.redhat.com/en_us/USA/home/services/ |
81 |
|
82 |
Their reading font is large, but the fonts associated with the design (nav |
83 |
bar items, side bar, legal, etc.) are not being blown out of proportion. |
84 |
People are not going to be reading these elements for hours on end, so it's |
85 |
okay. If you consider your _main_ audience, it's irrational to worsen the |
86 |
experience for 99% of the people so that the other 1% can have an ok |
87 |
experience. Redhat's reading font is already on the large end of what is |
88 |
acceptable in a professionally designed site. |
89 |
|
90 |
The other problem with setting the default font so large, is that if you |
91 |
increase the font size just by a little bit, everything will go nuts. |
92 |
|
93 |
E.g. http://www.aaronshi.com/gentoo/problems/aaronsplus2.png VS. |
94 |
http://www.aaronshi.com/gentoo/problems/liveplus2.png |
95 |
|
96 |
Both of the above were increased by 2 sizes in Firefox. What I'm getting at |
97 |
is that if people set their browser defaults just a bit larger, then |
98 |
everything would explode. In reality, it's more likely that people will set |
99 |
their browser defaults larger rather than smaller. The odds of it being |
100 |
blown up due to us setting a large default font is even greater in that |
101 |
respect. |
102 |
|
103 |
|
104 |
> Purple background with yellow text is hideous. Not going to happen. |
105 |
|
106 |
It's pea green. If we consider color theory, this shade of green is much |
107 |
more in line with our shade of purple (they are as best of a match between |
108 |
purple and green as you can get). The saturation is also much closer (69% |
109 |
vs. 70%) where as with the live site green it's (69% vs. 100%). This live |
110 |
site green, when viewed on (proper) displays, actually causes eye strain |
111 |
because the colors are _unnatural_ together. |
112 |
|
113 |
Green vs. yellow: http://www.aaronshi.com/gentoo/problems/greenvsyellow.png |
114 |
|
115 |
Pea Green (top) vs. Live Site Green (bottom): |
116 |
http://www.aaronshi.com/gentoo/problems/greentest.png The bottom one hurts |
117 |
doesn't it? |
118 |
|
119 |
|
120 |
> The "Locator" would require rewrites of not only the XSL but also the |
121 |
> actual xml files and is outside the scope of this project. |
122 |
> Touching any |
123 |
> xml content file is strictly off limits, all existing xml should be |
124 |
> backwards compatible with the new design. This point is not |
125 |
> debatable. |
126 |
> Use of a database would make this task easier while allowing |
127 |
> backwards |
128 |
> compatibility but it will have to wait for a future update to |
129 |
> the site |
130 |
> to be implemented. |
131 |
|
132 |
Fair enough. |
133 |
|
134 |
|
135 |
> The contents of the uppermost menu are to sites that are outside the |
136 |
> www.gentoo.org website. They will stay in this location. They |
137 |
> are green |
138 |
> to contrast with the purple background to ensure that colorblind and |
139 |
> other visually impaired people can see it. Green is the compliment to |
140 |
> purple so I am baffled that people think the combination is not |
141 |
> attractive. In Aarons preview the light purple color of these |
142 |
> links is |
143 |
> not visible to color blind individuals thus it is unacceptable. This |
144 |
> color will not change. |
145 |
|
146 |
The contrast between the purples should be enough, the lighter purple is |
147 |
roughly 2x brighter than the darker purple. The green makes it standout too |
148 |
much, especially the live site green. It's distracting. Originally, this |
149 |
element was intended as an indicator (to complement the locator) of the |
150 |
Gentoo network site a user is on. If we come back to asking the fundamental |
151 |
questions, by looking at any given page do I know where I am? After |
152 |
browsing around, am I still on the same sub site? Or have I gone from main |
153 |
to planet to bugs to ...? I understand this is a lost cause, but it's good |
154 |
to know that a "locator" of some sort is being considered for the future. |
155 |
Breadcrumbs have been a rather standard feature since the late 90s. |
156 |
|
157 |
|
158 |
> The grey menu should contain links that would be used in |
159 |
> order of a new |
160 |
> user and that highlight the main parts of the site. I did |
161 |
> this quickly |
162 |
> to have something there to look at. I didn't notice any good |
163 |
> suggestions |
164 |
> to replace what is there. If you have suggestions please send |
165 |
> them. The |
166 |
> same goes for the wording in the purple boxes, if you don't like what |
167 |
> they say submit a suggestion for each. Suggestions of "I |
168 |
> don't like it |
169 |
> you should change it" that don't include a clearly worded replacement |
170 |
> will be ignored. The donate box is here to stay until the search |
171 |
> function is implemented. |
172 |
|
173 |
Agreed. I think what we're both noticing here is that we're building the |
174 |
house from top to bottom rather than from the ground up. The information |
175 |
architecture should be in place and/or optimized before the design is ever |
176 |
started. Oops, scratch that, if I recall I think swift made a site map |
177 |
somewhere... The issue of what goes in the nav bar has been raised before |
178 |
and there was a semi-resolution to it. |
179 |
|
180 |
|
181 |
> Graphics should be implemented in the CSS as much as possible to aid |
182 |
> future maintenance (the xsl templates are huge and not easy |
183 |
> to maintain. |
184 |
> The least amount of editing of these files as possible is one of the |
185 |
> major goals). In text browsers that can handle graphics but don't |
186 |
> support CSS the upper left logo (which is a background image |
187 |
> so it can |
188 |
> be put in the css) will not appear but will leave space for |
189 |
> the missing |
190 |
> background image. I can't figure out a way around this. If you have a |
191 |
> suggestion I would appreciate it. |
192 |
|
193 |
I tried to do everything in CSS, which is why having a printable version of |
194 |
the site (http://www.aaronshi.com/gentoo/guidepageprint.html) is easy. |
195 |
Nothing is changed. No CSS files are changed. The _only_ difference is |
196 |
that the print CSS file is added to the end of the cascade, so that the |
197 |
print CSS rules overrides certain elements we want to redefine for print. |
198 |
Basically, with the logically structured HTML, we can change the design a |
199 |
whole lot without touching the HTML simply by manipulating the CSS. I.e. I |
200 |
had in mind different themes and elements for xmas, halloween, etc. and only |
201 |
an extra CSS file is required to add the changes (without touching the |
202 |
existing CSS files). |
203 |
|
204 |
|
205 |
> Horizontal scrolling of the entire page when a code listing is wider |
206 |
> than the page only happens in IE. All other browsers |
207 |
> understand the CSS |
208 |
> scroll:auto tag and will only scroll the actual code listing. |
209 |
> The same |
210 |
> applies to inline images within the page contents. IE is broken but I |
211 |
> did everything I could to make it behave the same as other browsers. |
212 |
> This is one issue that IE is simply broken on and there is |
213 |
> nothing I can |
214 |
> do to fix that. Javascript fixes are available but the use of |
215 |
> Javascript |
216 |
> is strictly forbidden. Javascript is not debatable. |
217 |
|
218 |
I think this problem was fixed in my reference page, some googling uncovered |
219 |
the solution (http://www.aaronshi.com/gentoo/guidepage.html). If in IE, |
220 |
scale down the window, the scroll bars will automatically appear on the code |
221 |
listing when necessary. It behaves identically as in Firefox etc. I'm not |
222 |
too sure what you mean by the inline image problem, can you explain (maybe a |
223 |
demo is easier)? |
224 |
|
225 |
|
226 |
> The <hr /> tags in the Handbook navigation are contained within the |
227 |
> handbook xsl template. Touching that file is outside my scope. |
228 |
|
229 |
They look ok anyway, but we can probably add a CSS rule to make it nicer if |
230 |
necessary. |
231 |
|
232 |
|
233 |
> The site is not XHTML it is HTML-4.01 Transitional and it |
234 |
> passes the w3c |
235 |
> validator. Manually overriding HTML-4.01 Transitional in the w3c |
236 |
> validator is not required and any errors that it reports if |
237 |
> you do this |
238 |
> will not be addressed. If you can come up with a good |
239 |
> technical reason |
240 |
> why doing this would benefit anyone I will address it. |
241 |
|
242 |
The differences between the two specs (at least HTML 4.01 vs. XHTML 1.0; -- |
243 |
1.1+ is another story) are not really that significant. I don't see why we |
244 |
can't switch to XHTML unless there are inherent coding in the system that we |
245 |
can't mess with. |
246 |
|
247 |
|
248 |
> Navigation and useability studies are beyond my scope. These issues |
249 |
> should have been addressed a year ago. |
250 |
|
251 |
I tried to address those issues (with pages of explainations etc.), but my |
252 |
suggestions were completely ignored. Hence, I won't say anymore about this. |
253 |
|
254 |
|
255 |
> The left hand navigation column is dead. No amount of beating |
256 |
> this dead |
257 |
> horse will resurrect it. The jumppads will remain at the bottom and |
258 |
> appear on all non-documentation pages so that those links are |
259 |
> accessible |
260 |
> as much as possible. |
261 |
|
262 |
We can also make additional jump pads if necessary. I only did 3 for the |
263 |
sample. |
264 |
|
265 |
|
266 |
> In Aarons preview the search box and the ads column are placed with a |
267 |
> Position:absolute and has it's size set. At resolutions below 800x600 |
268 |
> this makes the ads overlap the content and the search box overlap the |
269 |
> box to the left on every browser. When content is scarce the |
270 |
> ads overlap |
271 |
> the footer. This is not fixable given the current state of |
272 |
> css support |
273 |
> in the various browsers. After many many many long hours of |
274 |
> research and |
275 |
> experimentation I decided that we would have to resort to a table for |
276 |
> the ads column and include the search (now donate) box within the div |
277 |
> that contains the four purple boxes with a % width to fix |
278 |
> this issue. I |
279 |
> lowered the % width of the donate box and increased the |
280 |
> others to bring |
281 |
> it more inline with Aarons original design. It's not perfect but it's |
282 |
> close enough. |
283 |
|
284 |
It looks fine at 700x500. Even smaller at 640x480, it's still ok. This is |
285 |
because there's a min-width rule specified for the content area. Modern |
286 |
browsers should respect this rule (IE doesn't, but Firefox, etc. and Opera |
287 |
are fine). |
288 |
|
289 |
http://www.aaronshi.com/gentoo/problems/700x500ref.png |
290 |
|
291 |
Speaking of lower resolutions, the author credits takes up the entire screen |
292 |
(http://www.aaronshi.com/gentoo/problems/700x500live.png). I originally |
293 |
thought about doing it this way, but after trying with that same author list |
294 |
it didn't seem right. Hence the design was reworked to use the side bar, as |
295 |
old Gentoo site does, for author listings. It seems to work better. |
296 |
|
297 |
The side bar overlapping the footer when there is minimal content is a known |
298 |
issue. It's not as if we have the handbook in the footer. ;) The |
299 |
alternative is to have the footer block the bottom of the side bar, but the |
300 |
implementation is much more convoluted that it's not worth it. On the other |
301 |
hand, the side bar in the live site stops abruptly if the content is long. |
302 |
If content is the main focus, does it make sense to show a whole page's |
303 |
worth of white space just so the sidebar can display entirely? |
304 |
|
305 |
|
306 |
> Accessibilty guidelines say that all text links should be |
307 |
> underlined. I |
308 |
> made an exception for the grey menu bar for aesthetic |
309 |
> purposes but will |
310 |
> not make an exception for any other links. |
311 |
|
312 |
My thoughts exactly, although the author list is missing the underlines. |
313 |
|
314 |
|
315 |
> gentoo.org and all domains owned by the Gentoo Foundation |
316 |
> should render |
317 |
> correctly in all browsers that are still in general use. IE5 |
318 |
> on the mac |
319 |
> is still a valid browser and will be supported as much as possible. |
320 |
|
321 |
In my own site logs, Netscape 4 still out numbers IE5 for Mac (go figure). |
322 |
It's a simple cost/benefit analysis and in the end is it worth it to support |
323 |
such non-standard-compliant browsers? What message are we sending? --- we |
324 |
try to accommodate a few at the cost of the majority? |
325 |
|
326 |
|
327 |
> Summary and authors are important and should be prominently displayed |
328 |
> before the actual content. On the current design they are on |
329 |
> the right |
330 |
> in a tiny column that wraps every two words. This is |
331 |
> unacceptable. These |
332 |
> items will stay at the top for now unless someone can come up with a |
333 |
> place to put them that makes sense, looks good, allows the |
334 |
> summary to be |
335 |
> seen on top and not below the content (because a summary |
336 |
> should be above |
337 |
> the content otherwise why have a summary if you have to |
338 |
> scroll past the |
339 |
> content to see it?). The handbook is the only page that has a |
340 |
> large list |
341 |
> of authors and authors only appear on the first page so this |
342 |
> should not |
343 |
> be a problem. |
344 |
|
345 |
I had placed the title, summary, date modified (highlightly prominently in |
346 |
it's own box) at the top, and the authors on the side. It's the best I |
347 |
option I could come up with that doesn't kill usability (see my point a few |
348 |
paragraphcs above re: author list filling entiring screen; see my previous |
349 |
email re: what is usability). |
350 |
|
351 |
|
352 |
> *Background color for content was made light grey with black text for |
353 |
> better visibility of the text. Bright monitors should no longer be a |
354 |
> problem. |
355 |
|
356 |
Background should remain white, it's much easier to work with. To make it |
357 |
easier on the eyes, just lighten up the text a little (i.e. so it's not |
358 |
black on white which is high contrast but high contrast also strains the |
359 |
eyes after prolonged reading). I used #515151, which is 81% gray. The |
360 |
other point for not having colored backgrounds is that it looks particularly |
361 |
bad on laptops running on battery. When the screen dims when it's not on |
362 |
AC, it's all over. |
363 |
|
364 |
|
365 |
> *background color of the ads was made darker to contrast with the |
366 |
> content area. Decorative header was added. |
367 |
|
368 |
Please check the original colors, I think that was sufficient in boxing that |
369 |
area while leaving the text readable. |
370 |
|
371 |
|
372 |
> *all extraneous information and decorative news headers were removed |
373 |
> from the front page to help readability and to bring focus to the |
374 |
> information. This includes the cow image and text. |
375 |
> Overwhelming amounts |
376 |
> of information on the front page should no longer be a problem. This |
377 |
> also brings the jumppads closer to the top so new users will |
378 |
> be better |
379 |
> able to spot them. |
380 |
|
381 |
If decoration is used sparingly, it's great. If we want to be purely |
382 |
information based, and ignore appearance and marketing, we could go text |
383 |
only. |
384 |
|
385 |
|
386 |
> *table borders are now collapsed and only 1px thick. They are |
387 |
> no longer |
388 |
> ugly. |
389 |
|
390 |
Getting better... |
391 |
|
392 |
|
393 |
> *The purple boxes below the grey menu bar now only appear on |
394 |
> the main index. |
395 |
|
396 |
Perfect, that was the original intention. |
397 |
|
398 |
|
399 |
Some other points: |
400 |
- margins! Do books, magazines, newspapers not have margins? Keep it |
401 |
familiar for the readesr. |
402 |
|
403 |
- In IE, the top content starts ok, as you scroll down, everything shifts to |
404 |
the left. If it's a long page, by the time you get to the bottom, 20% of |
405 |
the content is out of bounds (to the left). E.g. |
406 |
http://wwwredesign.gentoo.org/doc/en/handbook/handbook-x86.xml?part=1&chap=8 |
407 |
The last sentence which says "You may now continue with Installing Necessary |
408 |
System Tools." only reads "ith Installing Necessary System Tools." |
409 |
|
410 |
- It's probably a good idea to add Arial to the fonts in CSS. Right now |
411 |
we're leaving out the 90% of the PC market. |
412 |
|
413 |
Hope that helps. |
414 |
|
415 |
Aaron |
416 |
|
417 |
-- |
418 |
www-redesign@g.o mailing list |