1 |
Hi all, |
2 |
|
3 |
Time is becoming extra rare these days, so I'll make this quick. |
4 |
|
5 |
Concerns regarding long author list have been addressed with this new |
6 |
update. The author list is moved to the "Sidebar" along with the document |
7 |
action buttons. As a result, long author lists now display fine, but it is |
8 |
not displayed when printed because it no longer follows the document "flow" |
9 |
-- which is fine as it wouldn't make sense to have 25% of the page width |
10 |
used by credits when printed anyway. The authors are credited online where |
11 |
the individual must've first visited before printing the page. In the case |
12 |
of a 1 document = 1 webpage type exclusively made for printing, then having |
13 |
all the authors at the top would be fine...almost like a book. |
14 |
|
15 |
Are there any other ways to do this? Throw out some ideas. Someone |
16 |
mentioned grouping the contributors under categories e.g. author, reviewer, |
17 |
etc., and someone mentioned hiding it using scripts. This is a common |
18 |
practice these days with Javascript/CSS. I did not do this as it concerns |
19 |
credits and the default state is to hide the info, hence contributors are |
20 |
not being given due credit when users disable their scripting capabilities. |
21 |
I'd like to explore this avenue but don't want to waste time if most |
22 |
disapproves the method. |
23 |
|
24 |
|
25 |
By some pure luck (I had no idea this existed), I stumbled upon the test |
26 |
server at http://wwwredesign.gentoo.org/ |
27 |
|
28 |
Looks like it's in progress, but I hope when it's done it'll look more like |
29 |
the reference pages I provided. =D |
30 |
|
31 |
Quirks are common place when integration takes place, but in this case the |
32 |
design appears to be completely *destroyed.* At this point, integrators |
33 |
shouldn't be changing the CSS or the basic HTML structure (except for quirk |
34 |
squashing purposes). I am no longer adding "features" either, just |
35 |
addressing concerns in this mailing list. |
36 |
|
37 |
With regards to moving the sitemap link in the upper right corner, I have to |
38 |
voice some usability implications of removing it. Just briefly, it is the |
39 |
ONLY way to return to the root level of a *particular* Gentoo site (i.e. |
40 |
packages.gentoo.org, forums.gentoo.org, etc. etc.). It also indicates to |
41 |
users what site they're on -- combined with the breadcrumbs they allow users |
42 |
to navigate to the exact page without URL bar (i.e. in a magazine |
43 |
screenshot) or when the print URL footer is cut off. Clicking the Gentoo |
44 |
logo will return you to www.gentoo.org, but not to the homepages of the |
45 |
other "sites." You could change the Gentoo logo to point to the homepages |
46 |
of the other sites, but then it'll be inconsistent and this inconsistency is |
47 |
not indicated to the user (i.e. the user doesn't know that the target page |
48 |
has changed). The rule of thumb is if the site's primary navigation is |
49 |
horizontal then the sitemap should be listed in the footer of the page if |
50 |
there isn't space in the horizontal nav; if the site's primary nav is |
51 |
vertical, then sitemap should be listed as one of the lower items in the |
52 |
vertical nav. If the information flow up/down is structure well, the |
53 |
sitemap is only secondary. Information flow should not only be concerned |
54 |
with people getting to places, but also getting back, knowing where they |
55 |
are, knowing what to expect up/down the flow, and it should be "intuitive." |
56 |
|
57 |
|
58 |
I'm not concerned about making the design work here and now, by definition |
59 |
it'll already be obsolete by the time your read this. My concern is making |
60 |
sure this design works now and in the future, taking growth and |
61 |
human/technological changes into account. |
62 |
|
63 |
All in all, I think the test site is off to a good start, allowing you to |
64 |
navigate many pages with a rough implementation of the design. |
65 |
|
66 |
Another concern, please refrain from leaking work-in-progress to the general |
67 |
public -- this practice has historically generated more problems than it |
68 |
solves. If the public needs to be updated, then planned and |
69 |
Gentoo-coordinated updates are the way to go, i.e. someone put together a |
70 |
package specifically for the purpose of a press release. |
71 |
|
72 |
This ended up longer than I thought, but there you go. |
73 |
|
74 |
Cheers, |
75 |
Aaron |
76 |
|
77 |
P.S. Michael, haven't heard from you in a while, hope all is well with you. |
78 |
Are you working on the test server?...I can no longer access your DSL hosted |
79 |
site. Activity on the list has been nil for 2 months, we didn't move to a |
80 |
new list did we? |